*sigh* execute failed: ERROR: relation "cover_art_archive.index_listing" does not exist
2021-02-24 05503, 2021
_lucifer
alastairp: should i update beta as well?
2021-02-24 05520, 2021
alastairp
yeah, go for it
2021-02-24 05507, 2021
_lucifer
done :D
2021-02-24 05544, 2021
ruaok
yay, for releasing stuff on your first full day.
2021-02-24 05546, 2021
ruaok
!m _lucifer
2021-02-24 05546, 2021
BrainzBot
You're doing good work, _lucifer!
2021-02-24 05514, 2021
yvanzo
alastairp: Sorry, it seems it cannot be implemented with consul-template 0.16 being used by LB containers, it does not support keyOrDefault either.
2021-02-24 05559, 2021
alastairp
yvanzo: ok, no problem. I'll finish the consul-template 0.18 PR today and we'll release that too
2021-02-24 05501, 2021
yvanzo
Only solution that worked for listenbrainz-websockets-test is to hardcode "rabbitmq-prince" in template for now.
2021-02-24 05537, 2021
alastairp
thanks for folowing up the cause
2021-02-24 05526, 2021
yvanzo
Hi roger_that, I can try to help you with if you provide more info please: raw log excerpt (please use pastebin or gist) and the output of "admin/configure show".
2021-02-24 05502, 2021
roger_that has quit
2021-02-24 05506, 2021
ruaok
alastairp: quick question: where it the config.py file that is used by jenkins for testing?
2021-02-24 05526, 2021
alastairp
ruaok: in LB? I think it's just copied from the example file
I have one more endpoint to add, but I will do so in another PR, this one is large enough already.
2021-02-24 05532, 2021
_lucifer
thanks outsidecontext!
2021-02-24 05518, 2021
atj
shivam-kapila: atj
2021-02-24 05502, 2021
shivam-kapila
gotcha thanks
2021-02-24 05522, 2021
atj
Anyone seeing "Failed process was running: CREATE INDEX recording_idx_name ON recording (name);" when attempting to import the sample data into the docker db instance?
shivam-kapila: TBH I think the cleaning up should be done server-side befoere sending through websockets. Where can I see the code you talk about in "even after serialising it as a Listen in frontend"?
2021-02-24 05512, 2021
Mr_Monkey
I can see that track_metadata doesn't have recording_msid in the WS listen (it's instead one level up)
2021-02-24 05521, 2021
shivam-kapila
its top level
2021-02-24 05548, 2021
shivam-kapila
and there are a lot of things like SUPPORTED_KEYS, date, dedup_tag etc which we dont need
That line does no transformation, it's just a typescript hint about what it should expect the type to be.
2021-02-24 05510, 2021
Mr_Monkey
So as far as I know we don't transfrom or sanitize the arriving WS message
2021-02-24 05518, 2021
atj
yvanzo: thanks appreciate you checking, it must be something on my side. I seem to spend more time battling with getting the docker instances working than actually doing any coding, so it's a bit frustrating!
2021-02-24 05531, 2021
shivam-kapila
Mr_Monkey: oh okay my bad. Is there a better way to discard these unnecessary keys rather than deleting them individually
2021-02-24 05507, 2021
Mr_Monkey
That should be done server-side to avoid sending a whole bunch of data we don't need
2021-02-24 05508, 2021
Mr_Monkey
and also to fix the original issue which is the misplaced recording_msid key
2021-02-24 05533, 2021
shivam-kapila
okay. IIRC ruaok had some concerns about doing this server side when _lucifer was onto it.
2021-02-24 05546, 2021
_lucifer
that was the original intent. but it adds another serializing/deserializing step so it was decided to do on the client side
2021-02-24 05555, 2021
shivam-kapila
Imo we can move the recording_msid to the required position and add a comment that ws message contains a lot of unnecessary info. Does this sound okay?
2021-02-24 05502, 2021
_lucifer
it is intended to use protobuf or some other solution and then do this server side
2021-02-24 05539, 2021
shivam-kapila
_lucifer: how does the above solution sound to you?
2021-02-24 05533, 2021
_lucifer
shivam-kapila: sounds good to me. but Mr_Monkey might have a better solution
2021-02-24 05511, 2021
Mr_Monkey
Can't really think of anything better to do if we don't want to handle it server-side.
2021-02-24 05511, 2021
Mr_Monkey
We're already deserializing so there's that.
2021-02-24 05512, 2021
shivam-kapila
okay. I will add a comment till then and also add a test for moving keys in the ws message
2021-02-24 05526, 2021
atj
Is JSON sent over the WS connection?
2021-02-24 05530, 2021
_lucifer
yes
2021-02-24 05534, 2021
shivam-kapila
yep
2021-02-24 05553, 2021
atj
So you're instantiating an object from JSON sent by via WS?
2021-02-24 05559, 2021
atj
s/by//
2021-02-24 05551, 2021
alastairp
atj: did you sort out the docker+mac issue?
2021-02-24 05501, 2021
atj
alastairp: no not yet
2021-02-24 05510, 2021
alastairp
I've seen errors importing the full MB database before when the docker machine didn't have enough memory allocated to it
2021-02-24 05526, 2021
alastairp
that is, shared buffers * 4 was > memory allocated to docker VM
2021-02-24 05532, 2021
atj
alastairp: I left it for a while to reduce the risk of me throwing my Macbook out of the window :)
2021-02-24 05507, 2021
atj
alastairp: thanks, good point, I've bumped the memory up to 5GB
2021-02-24 05515, 2021
shivam-kapila
> So you're instantiating an object from JSON sent by via WS?
2021-02-24 05515, 2021
shivam-kapila
atj: yeah
2021-02-24 05500, 2021
atj
shivam-kapila: on that line you linked to you have "json as Listen', where is the JS Listen object defined? (sorry might be a stupid question)
