NOTICE: MBBE-104 (https://tickets.metabrainz.org/browse/MBBE-104): Mark all leesmusic.co.kr links as ended
2025-11-27 33118, 2025
petitminion joined the channel
2025-11-27 33138, 2025
petitminion has quit
2025-11-27 33113, 2025
petitminion joined the channel
2025-11-27 33143, 2025
wargreen has quit
2025-11-27 33158, 2025
Maxr1998_ joined the channel
2025-11-27 33149, 2025
Maxr1998 has quit
2025-11-27 33106, 2025
monkey[m]
<lucifer[m]> "monkey: do you have the problema..." <- I do not have it no, not sure how I would extract it as I don't really know this system at all and the logs only complained about the keyerror.
2025-11-27 33106, 2025
monkey[m]
However it wasn't just one listen, the logs were full of the same error after I deployed the hotfix, so I suppose it could be an import from some service.
monkey: yes i was able to find the listens through sentry. it seems like someone submitted a custom jsonl file as LB import file.
2025-11-27 33101, 2025
monkey[m]
Woo!
2025-11-27 33123, 2025
monkey[m]
I think that's bound to happen. Glad I caught that validation issue
2025-11-27 33131, 2025
lucifer[m]
as for the timescale writer fix, it broadly looks correct to me but i am working on adding a dead letter queue so that the failing listens are not just dropped but stored separately for us to check later.
2025-11-27 33156, 2025
lucifer[m]
with just the fix in your pr, we risk dropping listens entirely.
2025-11-27 33117, 2025
monkey[m]
Yeah, that's the part I was really not sure about last night, looked like the listen would just be dropped and didn't know if they ended up in a retry queue or something
2025-11-27 33153, 2025
lucifer[m]
i'll add the requeue part. and let's update the hotfix after that
2025-11-27 33119, 2025
monkey[m]
Meanwhile we're also working (with failure ) on the front-end side of this issue, adding validation feedback to the importers, so users can know if listens were rejected
2025-11-27 33137, 2025
monkey[m]
Won't currently say which listens, just the count, but it's something
NOTICE: LB-1876 (https://tickets.metabrainz.org/browse/LB-1876): File importer should report failed listens
2025-11-27 33154, 2025
pite has quit
2025-11-27 33137, 2025
reosarevok[m]
bitmap: I'm looking at MBS-13984 - I was thinking the least bad way of doing this might be something like `root/static/scripts/common/components/CollapsibleList.js`
NOTICE: MBS-13984 (https://tickets.metabrainz.org/browse/MBS-13984): Reduce space used on Release pages by associated Recordings' streaming/download links
2025-11-27 33156, 2025
reosarevok[m]
I'm not sure whether we'd want a CollapsibleTable, or whether this should just be a general part of StaticRelationshipsDisplay where every table longer than X should be collapsible and collapsed by default...
2025-11-27 33104, 2025
reosarevok[m]
Any opinions?
2025-11-27 33119, 2025
derat[m] joined the channel
2025-11-27 33119, 2025
derat[m]
<reosarevok[m]> "derat: MBBE-104 seems right up..." <- indeed, i'll take care of it :-)
[bookbrainz-data-js] 14MonkeyDo merged pull request #327 (03master…dependabot/npm_and_yarn/js-yaml-4.1.1): chore(deps): bump js-yaml from 4.1.0 to 4.1.1 https://github.com/metabrainz/bookbrainz-data-js/…
2025-11-27 33142, 2025
milkii joined the channel
2025-11-27 33149, 2025
pite joined the channel
2025-11-27 33130, 2025
bitmap[m]
<reosarevok[m]> "I'm not sure whether we'd want a..." <- I'd just start with only URL lists longer then X items getting collapsed. the only problem is that I'm not sure every component using StaticRelationshipsDisplay is hydrated
reosarevok: any idea about what end date should be used for MBBE-104? i can just mark them as ended without a date if that seems reasonable and you can't find anything either...
