[listenbrainz-android] 14dependabot[bot] opened pull request #599 (03dev…dependabot/github_actions/dev/actions/setup-java-5): Bump actions/setup-java from 4 to 5 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29541, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #600 (03dev…dependabot/github_actions/dev/yutailang0119/action-android-lint-5): Bump yutailang0119/action-android-lint from 4 to 5 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29544, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #601 (03dev…dependabot/github_actions/dev/actions/github-script-8): Bump actions/github-script from 7 to 8 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29549, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #602 (03dev…dependabot/github_actions/dev/actions/checkout-5): Bump actions/checkout from 4 to 5 https://github.com/metabrainz/listenbrainz-androi…
[listenbrainz-android] 14dependabot[bot] opened pull request #606 (03dev…dependabot/gradle/dev/com.google.devtools.ksp-2.3.0): Bump com.google.devtools.ksp from 2.0.0-1.0.23 to 2.3.0 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29504, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] closed pull request #493 (03dev…dependabot/gradle/dev/com.google.devtools.ksp-2.0.21-1.0.25): Bump com.google.devtools.ksp from 2.0.0-1.0.23 to 2.0.21-1.0.25 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29518, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #607 (03dev…dependabot/gradle/dev/com.patrykandpatrick.vico-compose-2.3.0-alpha.2): Bump com.patrykandpatrick.vico:compose from 2.0.0-alpha.22 to 2.3.0-alpha.2 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29520, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] closed pull request #486 (03dev…dependabot/gradle/dev/com.patrykandpatrick.vico-compose-2.0.0-beta.1): Bump com.patrykandpatrick.vico:compose from 2.0.0-alpha.22 to 2.0.0-beta.1 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29524, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #608 (03dev…dependabot/gradle/dev/io.sentry.android.gradle-5.12.1): Bump io.sentry.android.gradle from 4.10.0 to 5.12.1 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29526, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] closed pull request #492 (03dev…dependabot/gradle/dev/io.sentry.android.gradle-4.12.0): Bump io.sentry.android.gradle from 4.10.0 to 4.12.0 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29520, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #609 (03dev…dependabot/gradle/dev/org.mockito-mockito-core-5.20.0): Bump org.mockito:mockito-core from 5.12.0 to 5.20.0 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29524, 2025
_BrainzGit
[listenbrainz-android] 14dependabot[bot] closed pull request #491 (03dev…dependabot/gradle/dev/org.mockito-mockito-core-5.14.2): Bump org.mockito:mockito-core from 5.12.0 to 5.14.2 https://github.com/metabrainz/listenbrainz-androi…
2025-10-22 29508, 2025
v6lur has quit
2025-10-22 29513, 2025
wargreen has quit
2025-10-22 29548, 2025
wargreen joined the channel
2025-10-22 29505, 2025
d4rk joined the channel
2025-10-22 29535, 2025
d4rk-ph0enix has quit
2025-10-22 29508, 2025
julian45[m]
tickets website (jira) will be going down shortly to apply security updates. expected to be back online within a few minutes following updates
2025-10-22 29547, 2025
julian45[m]
all done! :)
2025-10-22 29531, 2025
fettuccinae[m]
<TalibHussain[m]> "i am having this issue now may..." <- I feel like this is some macOS quirk. Did you try restarting docker?
2025-10-22 29509, 2025
pite joined the channel
2025-10-22 29559, 2025
jasje[m]
Oh boy i need to turn of dependabot
2025-10-22 29514, 2025
jasje[m]
s/of/off/
2025-10-22 29551, 2025
Kladky joined the channel
2025-10-22 29500, 2025
jasje[m]
lucifer: possible to set now listening to nothing?
2025-10-22 29546, 2025
lucifer[m]
jasje: no but we can add an endpoint for that.
2025-10-22 29522, 2025
jasje[m]
lucifer: that would be great! I'll create a ticket on Jira
zas: lucifer I have healthchecks.io now doing the cron monitoring. is there any reason for us to keep our self hosted instance of sentry or can I nuke it out of the sky with great joy?
[musicbrainz-server] 14mwiencek merged pull request #3649 (03production…subscriptions-weekly-only): Allow running ProcessSubscriptions for weekly only https://github.com/metabrainz/musicbrainz-server/…
2025-10-22 29533, 2025
reosarevok[m]
bitmap: hi!
2025-10-22 29542, 2025
reosarevok[m]
yvanzo: assuming you're off, but just in case, also hi!
2025-10-22 29549, 2025
reosarevok[m]
(and if you're off, enjoy!)
2025-10-22 29500, 2025
bitmap[m]
hey
2025-10-22 29555, 2025
reosarevok[m]
How's the week going? :)
2025-10-22 29533, 2025
bitmap[m]
I've been monitoring the ProcessSubscriptions script from last night (which is still running)
2025-10-22 29554, 2025
bitmap[m]
it might only be taking longer than usual because the previous day was skipped. but I'm trying to identify editors that are taking a while (one took about an hour to process, which is unusual)
2025-10-22 29522, 2025
bitmap[m]
sending the emails doesn't appear to be a bottleneck at least, it looks like most time is spent calling Data::Edit::find_for_subscription. though the performance will depend on what the subscription is
2025-10-22 29511, 2025
bitmap[m]
will be spending most of today looking into this probably
2025-10-22 29522, 2025
reosarevok[m]
Thanks! that does feel important
2025-10-22 29541, 2025
reosarevok[m]
Especially if we can make find_for_subscription more efficient and cut a good chunk of the time, which would not surprise me
2025-10-22 29503, 2025
reosarevok[m]
Alternatively, is there a way to run this in several goes at a time, a bit like our selenium tests?
2025-10-22 29536, 2025
bitmap[m]
well we could split off the subscriptions processing into a separate container and run them on different hosts, but that will add a lot of complexity, so I'm hoping I can identify improvements to the existing setup first
2025-10-22 29523, 2025
bitmap[m]
also I was looking through sentry issues and saw that the IA started returning "409 Client Error: Conflict for url" for our copy_image events in the artwork-indexer, though they went through successfully after a couple more attempts, so I'm hoping it was a transient issue and I don't have to bother them again :)
2025-10-22 29551, 2025
bitmap[m]
the copy_image events happen on release merges (to copy the images to the merge target)
I'd like to know Yvan's opinion, but I understand the point of that TODO is to not fail if a replication packet disappears for some reason?
2025-10-22 29503, 2025
reosarevok[m]
Not sure when and why that would ever happen
2025-10-22 29522, 2025
reosarevok[m]
(and isn't the system specifically built around loading them all in order)
2025-10-22 29556, 2025
bitmap[m]
I think the point is to check if we hit a 404, to check if there's a hit for the next sequence ID, then die with an error
2025-10-22 29545, 2025
bitmap[m]
it should fail in that scenario but it's not really necessary except to show a different error message
2025-10-22 29551, 2025
reosarevok[m]
But why wouldn't we die with an error anyway?
2025-10-22 29553, 2025
reosarevok[m]
Ah, ok
2025-10-22 29559, 2025
reosarevok[m]
Just to get a different error
2025-10-22 29516, 2025
bitmap[m]
right now it will just 404 forever
2025-10-22 29531, 2025
bitmap[m]
this is the kind of issue that people tend to notice and report right away though
2025-10-22 29533, 2025
reosarevok[m]
But if that happens, it'd happen to everyone and people would come to our forum and ask wtf, am I right?
2025-10-22 29535, 2025
reosarevok[m]
Yeah, that
2025-10-22 29516, 2025
reosarevok[m]
And in any way, the issue would have to be unblocked by us, wouldn't it? By restating the missing packet or whatnot
2025-10-22 29512, 2025
bitmap[m]
right, which has happened at least once in the past
2025-10-22 29530, 2025
reosarevok[m]
In that case, I'm ok with it being a todo for 13 more years tbh
2025-10-22 29508, 2025
reosarevok[m]
Which I think will mean in practice "implement this the next time the situation happens so we have a better error for the time after that" (and hopefully never use it, but)
2025-10-22 29527, 2025
bitmap[m]
I'd propose removing it and setting up proper monitoring for the available packets tbh
2025-10-22 29504, 2025
reosarevok[m]
I mean, "proper monitoring" sounds brilliant if that is easy enough :)
2025-10-22 29510, 2025
reosarevok[m]
(not just for this! :D )
2025-10-22 29526, 2025
reosarevok[m]
So, sure, works for me too
2025-10-22 29529, 2025
bitmap[m]
yeah, maybe we can discuss what the monitoring should look like when Yvan is back
2025-10-22 29553, 2025
reosarevok[m]
Seems good, he likes a good monitoring setup!
2025-10-22 29547, 2025
reosarevok[m]
For me, https://github.com/metabrainz/musicbrainz-server/… should be done and would be good to get into the next release to at least unbreak edit display (if the other bit needs further work we could split it)
