sorri assumed that the "follow me" button was an image
bitmap
ruaok: +1
ruaok
bitmap: reosarevok: looks good. it could use some boilerplate guff at the bottom: "We'll post final details about this release just prior to the release and shortly after we complete the release, we'll post instructions on how you can update your own copy.".
that's a beefy list -- good luck!
!m MB team
BrainzBot
You're doing good work, MB team!
bitmap
thanks!
shivam-kapila
CatQuest: anything visible in browser logs?
bitmap
reosarevok: made the changes ruaok mentioned
if they look ok feel free to hit publish
shivam-kapila
Mr_Monkey: there's a test missing for updateMode in FollowerFollwing Modal and a render test for SimilarUsers modal. Shall I add these?
alastairp
I get 4pm sun directly in my eyes when sitting at my desk only during summer
I think I'm going to need a summer house and a winter house
shivam-kapila
rich alastairp
Mr_Monkey
Yes please shivam-kapila !
HenryG has quit
akashgp09 joined the channel
HenryG joined the channel
reosarevok
bitmap: oh, yvanzo wanted zas to confirm that moving to 20.04 would be sensible
Hey, yvanzo and reosarevok I hope you folks are doing alright. My name is Saad. I am a Computer Science Junior at college. I am really interested in one of your GSoC 2021 projects of Pushing the URL relationship editor to the next level. I am an experienced JavaScript developer, specifically in React.js. I was looking for the repo to get better
understanding of the codebase but unfortunately, I couldn't find it. Can you please share the link so that I can get started? Thank you!
But yeah, it all seems to be there and working, and the code looks clean (to me). I haven't looked at the python parts much.
shivam-kapila
I am also reviewing and the python bits looks sane
Mr_Monkey
With that PR we're adding endpoints to the API. Is there anything we need to do regarding that? Are the docs all there?
shivam-kapila
The api endpoints lack docstrings
Mr_Monkey
Could you tackle that too please?
shivam-kapila
ok will do
alastairp
_lucifer: that still looks suspicious to me. https://github.com/plamere/spotipy/blob/master/... shows that it directly returns the `requests` Response.headers dict. I don't think that requests does anything magic with numbers
in fact, I just did a quick test and got this response:
If the owner is the only item in the collaborators list, it will be removed by that bit of code, and as a consequence we pass an empty list to `get_many_users_by_mb_id`, and it doesn't like that (SQL exception about `IN ()`)
and I see that you did mention this in the PR body too
Mr_Monkey
I haven't used sentry much; am I supposed to resolve those if they are fixed?
alastairp
yes, that'd be good
because then it'll alert us again if it happens again
Mr_Monkey
Yeah, it's obvious now that I phrase it :p
alastairp
I don't use sentry very well either
RikkoM has quit
msaaddev has quit
_lucifer
assuming spotify follows the Oauth spec for invalid grant, `invalid_grant` can also occur if our credentials or redirect uri is incorrect.
>The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
alastairp, should we add a check for this?
alastairp
in which place? while a user is doing the auth workflow?
_lucifer
in `refresh_user_token`
in case `refresh_user_token` gets an `invalid_grant` it will unlink the user.
alastairp
"does not match redirect uri" seems a bit weird
does that mean that if we changed the redirect url in our app, and then tried to refresh everyone, it'd fail?
_lucifer
that's from the OAuth Spec
alastairp
I just had a thought here too - we delete the row if the refresh fails
but doesn't the row include the error message?
_lucifer
yes, i think so and unlink all the users along the way
SothoTalKer has quit
i din't understand which row? the row for that user in spotify auth table?
SothoTalKer joined the channel
alastairp
sorry, yeah. spotify_auth
spotify_auth.error_message
_lucifer
yeah, right. that would be an issue.
dpmittal_ joined the channel
how about instead of deleting we update the error message or add a column to the table and check for a specific message or that field before processing a user?
alastairp
yeah, I'd be happy to have an active field
BrainzGit
[troi-recommendation-playground] mayhem merged pull request #34 (main…improved-mbid-mapping): Improved mbid mapping, playlist submit improvements and year lookup improvements. https://github.com/metabrainz/troi-recommendati...
_lucifer
makes sense.
alastairp
but if this PR allows us to update the spotify reader container then let's merge it and open a ticket for this and add it next
_lucifer
it will begin to error when we try to update the error message i think because the user is not present in the db
akashgp09 has quit
alastairp
ah, right
yeah, let's use exceptions to indicate that case then, and do all database work in process_one_user
_lucifer
ah actually it won't since we already a different exception
but yeah moving the logic to process_one_user is probably better to keep it one place and avoid confusion
RikkoM joined the channel
-- BotBot disconnected, possible missing messages --
so you're asking "should we catch expction; log; raise in process_one_user" or "just call refresh_user_token and catch/log in process_all_users"
bitmap
reosarevok: yvanzo: I'm wondering how we should deal with keeping these new materialized tables up-to-date on slave servers. they aren't replicated and slaves don't have triggers, we we'd either have to add a file for slave-only triggers, or regenerate the tables hourly after packets are applied
_lucifer
alastairp, yes
alastairp
the only thing I'd consider here is where we want to modify the database row. it doesn't make sense to modify a single user in process_all_users when there's an auth issue, and in process_one_user in all other cases
keeping it together in a single method would be easier I think
goapunk_ is now known as goapunk
having said that - I'm thinking through a use-case here: token hasn't expired, but when we try and get currently playing we get an exception because the user has revoked permission
in that case it sounds like we should wrap all of process_one_user in a try/except?
_lucifer
yeah, it kinda already is in process_all_users and that's the only place we call it