1 month, 3 months, 9 months, 2 years 3 months, 6 years 9 months, 20 years 3 months.
2025-04-10 10057, 2025
lucifer[m]
we allow a maximum of 10 passes but as you can see even 6 or 7 passes will cause a full table search.
2025-04-10 10027, 2025
lucifer[m]
i think we should not search more than 9 months in one pass.
2025-04-10 10033, 2025
BrainzGit
[musicbrainz-server] 14reosarevok opened pull request #3517 (03master…MBS-13982): MBS-13982: Wrap overlong release and release group titles in tables https://github.com/metabrainz/musicbrainz-server/…
2025-04-10 10000, 2025
mayhem[m]
<lucifer[m]> "i think we should not search..." <- seems senisible...
2025-04-10 10022, 2025
fettuccinae[m] joined the channel
2025-04-10 10022, 2025
fettuccinae[m]
<lucifer[m]> "i think we should not search..." <- I was trying to implement in such a way that we initially load data only for 30 days and then render a button which does the normal search.
2025-04-10 10022, 2025
fettuccinae[m]
If we limit each pass for 9 months, users with a gaps in their listening won't be able to fetch their older listens
2025-04-10 10030, 2025
fettuccinae[m]
* I was trying to implement in such a way that we initially load data only for 30 days and then render a button which does the normal search.
2025-04-10 10030, 2025
fettuccinae[m]
If we limit each pass for 9 months, users with a gaps in their listens won't be able to fetch their older listens
2025-04-10 10021, 2025
fettuccinae[m]
* I was trying to implement in such a way that we initially load data only for 30 days and then render a button which does the normal search.
2025-04-10 10021, 2025
fettuccinae[m]
If we limit each pass for 9 months, users with gaps of more than 9 months in their listens won't be able to fetch their older listens
2025-04-10 10047, 2025
lucifer[m]
fettuccinae[m]: > <@fettuccinae:matrix.org> I was trying to implement in such a way that we initially load data only for 30 days and then render a button which does the normal search.
2025-04-10 10048, 2025
lucifer[m]
> If we limit each pass for 9 months, users with gaps of more than 9 months in their listens won't be able to fetch their older listens
2025-04-10 10048, 2025
lucifer[m]
you would need to call the API again with the new from_ts/to_ts.
2025-04-10 10010, 2025
lucifer[m]
to load data for users with more gaps.
2025-04-10 10031, 2025
lucifer[m]
i think we should return a next/prev link in the API response to let the caller know the exact timestamps that we have already searched for and avoid redundant searches.
2025-04-10 10026, 2025
fettuccinae[m]
lucifer[m]: Ah yes, and if they got like multiple gaps, they can just call the api again. I'll limit the search window for each pass
2025-04-10 10041, 2025
lucifer[m]
for now though, i think you can just add a flag to fetch listens. example from_profile and set it to true for the initial load in the profile view.
2025-04-10 10032, 2025
lucifer[m]
when the frontend makes the API call to load more listens, it will just use the existing implementation and do multiple passes spanning the entire table.
2025-04-10 10022, 2025
lucifer[m]
when we have added prev/next links in the API response to aid navigation we can reduce the window size too.
2025-04-10 10035, 2025
fettuccinae[m]
lucifer[m]: I don't think we'd need a flag, because when the initial call is made, it's made without from_ts and to_ts,
2025-04-10 10003, 2025
fettuccinae[m]
<lucifer[m]> "i think we should return a next..." <- frontend does check the last listen's timestamp and makes the call for next/ more listens.
2025-04-10 10038, 2025
fettuccinae[m]
<lucifer[m]> "when the frontend makes the..." <- I was thinking if we could limit the window size in each pass, we could render the listens of first 9 months, then frontend could use the listened_at_ts of the last listen and use it as from_ts to make next api call.
2025-04-10 10006, 2025
fettuccinae[m]
* I was thinking if we could limit the window size in each pass, we could render the listens of first 9 months initially, if the listens are less than 25, frontend could use the listened_at_ts of the last listen and use it as from_ts to make the next api call for listens in next window.
2025-04-10 10010, 2025
lucifer[m]
@fettuccinae:matrix.org: yes but the backend has also likely searched for more time ranges.
2025-04-10 10001, 2025
lucifer[m]
for instance, think of a user with gaps in data where they have a couple of listens in last month and then no listens in 1 year. the frontend will make the API call with the timestamp of the listen from last month.
2025-04-10 10011, 2025
lucifer[m]
whereas the backend has already searched the last 9 months and didn't find any data. i mean to surface this information in the API for pagination. so that the frontend can avoid making redundant queries.
lucifer: do you know which redirect URIs are allowed for the jira auth integration with MB? or is that potentially not checked?
2025-04-10 10036, 2025
lucifer[m]
julian45: on BrainzBot side?
2025-04-10 10009, 2025
julian45[m]
On the side where we allow folks to log into Jira w/ their MB account
2025-04-10 10040, 2025
lucifer[m]
i see, yvanzo or bitmap would know that.
2025-04-10 10000, 2025
lucifer[m]
its not using the new MeB OAuth provider, but the MB.org one.
2025-04-10 10020, 2025
yvanzo[m]
julian45: Good catch
2025-04-10 10029, 2025
yvanzo[m]
Adding updating the callback URI to the steps
2025-04-10 10016, 2025
yvanzo[m]
Well, there is no update to do once the migration is over.
2025-04-10 10049, 2025
julian45[m]
hopefully the migration will not break the jira side config and require updates to the prod config on the MB side, but if we want to test login before cutting over tickets.MeB to point to the new server, it would be good for the new instance's domain name to be allowed
2025-04-10 10032, 2025
julian45[m]
* hopefully the migration will not break the jira side config and require updates to the prod config on the MB side (like a randomly generated string in jira's own callback URI or smth), but if we want to test login before cutting over tickets.MeB to point to the new server, it would be good for the new instance's domain name to be allowed
2025-04-10 10050, 2025
julian45[m]
ditto for the github login option as well
2025-04-10 10036, 2025
yvanzo[m]
Tickets will go offline in 30min from now.
2025-04-10 10013, 2025
SigHunter has quit
2025-04-10 10002, 2025
SigHunter joined the channel
2025-04-10 10004, 2025
aerozol[m]
Great ticket offline pic :)
2025-04-10 10008, 2025
monkey[m]
<lucifer[m]> "monkey: what issue are you..." <- I figured most of my issues out, thanks though!
