#metabrainz

iliekcomputers: Hi, I investigated into LB-609

^ this link returns a 204 response

^ this link returns a 404

Hence we get a type error

I guess the 204 from beta-api is not forwarded by production api

Actually looking at the error on beta.lb.org, it seems that forwarding is not the issue

The 204 response doesn't have the access-control-origin header

So we get a CORS issue

bitmap, yvanzo: https://tickets.metabrainz.org/browse/MBS-10875 opinion?

I assume we intentionally don't return them to limit the size of the response, but maybe it's too weird?

[musicbrainz-server] reosarevok opened pull request #1541 (master…MBS-10872): MBS-10873: Load ACs for annotation edits https://github.com/metabrainz/musicbrainz-serve...

hi reosarevok: It doesn’t seem weird to me, but if the only issue is “it looks weird” maybe it can be moved to ws/3?

rdswift: Even if intentional, the current behavior might just need to be documented at least?

Mo"in' 💥

Morning

Morning

[listenbrainz-server] vansika opened pull request #885 (master…metadata): save dataframe and model metdata in HDFS https://github.com/metabrainz/listenbrainz-serv...

prabal: looking at the logs, I see the error thrown is `Unrecognized entity type: 'Editor'`

Care to have a look at why that would happen?

Because in the code of main website

Editor case is not handled

Apparently, happens any time an editor is found, but not when no Editor matches the query

Is it handled in beta?

Yeah

Yes

OK, then I'll deploy today. My mistake.

I forgot es index is same for beta and main website

And asked you to reindex

If you do bookbrainz.org/search/reindex

It'll get fixed

iliekcomputers: ping

resetting test.mb.o

ishaanshah: morning

i haven't deployed master to the production API yet, so the 404 makes sense

[bookbrainz-site] prabalsingh24 opened pull request #435 (UserCollection…search-table-add-to-collection): UserCollection: Add to collections from search results https://github.com/bookbrainz/bookbrainz-site/p...

[listenbrainz-server] paramsingh merged pull request #884 (master…master): LB-610: The URL in the browser should update with parameters for the history page https://github.com/metabrainz/listenbrainz-serv...

Mr_Monkey, I'd say we publish -data-js for now. I think what I've done is sufficient to cover the work I'm doing.

OK, I'll aim to do that today

👍

And anyways, version numbers are cheap. :)

iliekcomputers: Please ping me when you are free, had to discuss some stuff about the request consumer code

i'm around

This the new code for artist stats

It will be similar for releases

We can't store a list of messages and then send them via rmq because of memory issues right

So we will have to write a similar function to this but which operates on the iterator

But as that function is used for recommendation too, we cant change it

So I was thinking that we should have messenger_map similar to query_map

the messenger_map will map the query type to the appropriate messaging function

hmm, let me think

i was looking into exploring making classes that inherit from an abstract RequestConsumerQuery for each query

So each class would implement its own handler and messenger?

right, we could have a default messenger, and the class could override it if it needs to

yvanzo: I guess the main issue is the lack of parity

Hmm, that will work too, but wont we have multiple rmq connections open?

ruaok: Ping

hmm, i haven't fleshed it out yet. i'll try to write it up in some more detail today.

Ok, I will keep the get_artist and get_release ready

pong!

Hey

The failing dump manager test is also fixed now

what was it?

Remember the 0 listens dumped log I sent you?

That was the cause. No listens had created in the dump formation range

ah, yes.

makes sense.

push your change, please.

Pushed. timescale-rebased-again

This shouldn't happen though as the previous dump id is added before inserting listens. Anyways I just made the previous dump ID time to be less by 5 sec.

Took 2.5 days to finally dig the issue :-|

one thing I was thinking of is that we should change the timestamps in our test data, to include a gap of more than 3 weeks.

I'm glad you found it, it looked totally opaque to me.

> one thing I was thinking of is that we should change the timestamps in our test data, to include a gap of more than 3 weeks.

Why so?

ishaanshah: did you figure out the issue with CORS?

Not yet, I am not sure why the server is not sending the header with 204 response

shivam-kapila: that would force us to deal with the time-range issues correctly. I think having closely spaced listens may be hiding problems for us.

Thats why the error boundary is not working

can you reproduce it in dev?

It works on dev

ruaok: Hm. Yeah I will agree to that

yeah, it worked for me too.

i do wonder tho, why it works for the artist endpoint and not for the release endpoint

shivam-kapila: can you please try it? add a few more listens that have a large gap and see what breaks?

artist endpoint is on api

!m shivam-kapila

You're doing good work, shivam-kapila!

release is on beta-api

maybe some config error on beta-api?

they're basically the same, but yeah, that could be a possibility

ruaok: Thanks.

> can you please try it? add a few more listens that have a large gap and see what breaks?

To the test JSON files right?

yes

I will give that a try. If things break I guess they would be in timescale_listenstore tests only but lets see

I'm not sure sure. all test pass now, thanks!!

changes pushed to main branch

[musicbrainz-android] amCap1712 merged pull request #39 (master…design-pattern): Refactor modules to avoid redundancy. https://github.com/metabrainz/musicbrainz-andro...