#metabrainz

lucifer: Hi! I'm in kiss updating beta and test, want me to update prod to v-2024-05-08.0 while I'm here?

monkey: yes please

Thanks!

mayhem: woo, crates!! Thanks

did you see how one is smaller than the others?

I noticed some size differences when I was testing it using browser tools. I think it’s down to the amount of text in the flexbox? I assume the other logo was a bit smaller there too - if not, spooooky

akshaaatt: jasje: FYI, Twitter user to the rescue re. resetting app login ^

Sounds great, aerozol[m] !

Not that great tbh

re. our response time/not answering the question

bitmap: Found a solution: Upgrading to Yarn v4 in xgettext-js repository. See the pull request’s description for details.

[listenbrainz-server] 14orontee opened pull request #2869 (03master…reference-mopidy-in-add-data-page): Reference Mopidy music player in "add data" page https://github.com/metabrainz/listenbrainz-serv...

yvanzo: awesome, thanks

[mbsssss] 14yvanzo merged pull request #65 (03master…solr-9-updates): SEARCH-685 (SolrCloud): Update cores’ common config after Solr 9 https://github.com/metabrainz/mbsssss/pull/65

[listenbrainz-server] 14MonkeyDo merged pull request #2869 (03master…reference-mopidy-in-add-data-page): Reference Mopidy music player in "add data" page https://github.com/metabrainz/listenbrainz-serv...

lucifer: Hello again, had a question for you. With the new SPA feature, we load data for each page using POST requests. Since we expect json, we get an ugly parsing error if the server returns an HTML error page instead.

This solves the issue in question, but I wanted to check with you if it is reasonable to return a jsonified error for all POST requests like so, I know I could be missing some edge cases: https://github.com/metabrainz/listenbrainz-serv...

monkey: i think we should use the Accept header instead of always returning json for errors on POST

frontend can set `Accept: application/json`. if present return errors in json otherwise html. for api, always json.

Hmm, currently looks like we use "Content-Type": "application/json",

Thanks

I saw application/json and didn't think it was the wrong header

Content-Type is for the response side.

Yep

Accept for request but it will still need to implemented on the backend fwiw.

was just proposing a solution to implement.

Ah OK. I'l see if I can figure it out

Thanks for the help!

lucifer: Figured out how to do it properly I think, thanks a lot !

Secondary question: looks like we do the check for 'is this an API request?' twice, but I think it's redundant and duplicates some code. Just to confirm with you, in the ISE handler (https://github.com/metabrainz/listenbrainz-serv...) we don't need the check since handle_error does a similar check, right?

(https://github.com/metabrainz/listenbrainz-serv...)

The difference I see is we set an "Access-Control-Allow-Origin" header.

sure otherwise let me know, i can implement it later today.

nah, it was easy: `or request.accept_mimetypes.accept_json:`

yes, i think that's redundant and can be simplified

Access-Control-Allow-Origin should be set always for errors, that's an oversight in ise error handler.

OK, thanks, I'll refactor the ISE handler too then

awesome, thanks!

[musicbrainz-server] 14yvanzo merged pull request #3258 (03master…fix-xgettext-js): Fix installing our xgettext-js fork using Yarn v4 https://github.com/metabrainz/musicbrainz-serve...

lucifer: I am actually going to need your help :sweat_smile:

Some of the errors (DatabaseException) handled by the ISE method don't like being handled like the other ones. I tried a few things to handle them but I don't know what I'm doing...

The branch in question is `spa-fixes`

monkey: will take a look

Thank you!

bitmap: Spotted a double issue around area containment using musicbrainz-docker@pg16 w/ musicbrainz-server@schema-change-2024-q2 w/ yarn patches from master.

_The function `get_area_parent_hierarchy_rows` does not exist_ from the sub `get_area_containment_join` in `lib/MusicBrainz/Server/Data/Utils.pm`.

The main issue seems to be that the latest sample data dump (2024-05-01) cannot be be imported correctly, thus stopping the process before creating functions. I will try to generate a new dump.

bitmap: My bad: musicbrainz-server@schema-change-2024-q2 can obviously not load a data dump from the current schema.

Worked around by using a branch with pg16 commits only.

The branch is `pg16-base` and doesn’t contain any breaking schema change.

yvanzo: thanks, that should be useful for me

I'm nearly done setting up a primary/standby clone of the prod DB on aretha

Also the branch `schema-change-2024-q2` is missing Yarn fixes.