[listenbrainz-server] mayhem opened pull request #727 (masterā¦no-spotify-dups): Do not submit previously submitted listens to the pipeline. untested! https://github.com/metabrainz/listenbrainz-serv...
ruaok
totally untested. I need to run off to lunch, but if you get a moment, sanity check my approach?
ruaok zooms off
iliekcomputers
ruaok: looks reasonable to me.
We could probably avoid the extra database call from getting the user again
Sophist_UK has quit
Gazooo has quit
Gazooo joined the channel
eharris has quit
Etua has quit
Sophist-UK joined the channel
Sophist-UK has quit
Sophist-UK joined the channel
Lotheric has quit
shivam-kapila has quit
eharris joined the channel
ruaok
hmm. ok, I can look again and see if that is doable.
endurance21 joined the channel
sarthak_jain joined the channel
sampsyo has quit
sarthak_jain
Hey pristine__
When I run `./spark_test.sh` locally, I am facing error stating `cannot create temporary directory` ?
iliekcomputers: I dont quite see an easy way to avoid the extra user fetch -- from what I can see we'd need to cache them in ram someplace and then ensure we're cleaning up, etc.
So it should already have the latest_listened_at property
ruaok
oh! right. I first thought that was a lb user object, not spotify, then realized that that was not the case.
lemme fix.
pushed.
iliekcomputers
looks good to me, do you have a local environment to test?
ruaok
not really.
iliekcomputers
yolo it and trust the automated tests?
ruaok
my plan was to add some debug statements and ensure that the right thing is happening and carefully watch for a while.
thankfully this is slightly less mission critical than the web site staying up.
so, not quite 'yolo it', but close. more like good ole testing in production. :)
but, given that I want to watch it over time, I'll wait until tomorrow to test it.
iliekcomputers
sounds good
ruaok
I'm still not 100% convinced that this is the root cause, but it should at least alleviate some symptoms.
sarthak_jain has quit
zas
experimental setup for livegrep is available at http://livegrep.metabrainz.org:8910 (WIP), please test and report issues, repos are re-indexed every 5 mins
ruaok
ohh, I like it.
I wanted to show pristine__ a badly named function and I couldn't find it. I was looking in the wrong codebase.
editing question: is there are policy for how to use work aliases for transliterations?
(or perhaps more specifically, is that the correct way of doing it? I don't see a work-work transliteration rel type. perhaps you could do rel-rel and create a new work and make the same recording-work relation as on the original release?)
reosarevok
Why would you have a new work for a transliteration? That's just a name change, no?
Work aliases seem like the only reasonable way, we don't have script for those at the moment but it's better than nothing
however, it is really interesting how the response time degrades when the queue is backed up.
which makes no sense to me yet.
alastairp
no strong reason to have a new work for a transliteration. alias feels better to me too. script would be great, but for now not a problem if we don't havve it. thanks
apetresc joined the channel
iliekcomputers
ruaok: response times of the submit listens endpoint or response times in general?
[mb-solr] dependabot[bot] opened pull request #35 (masterā¦dependabot/maven/mb-solr/org.apache.solr-solr-core-8.4.0): Bump solr-core from 7.7.2 to 8.4.0 in /mb-solr https://github.com/metabrainz/mb-solr/pull/35
reosarevok
You might not be able too, hence "useful!"
*to
bitmap: how bit is your bit :D
yvanzo
We can run it on test.mb.o if you want to.
reosarevok
How old is that data?
CatQuest
mega old
test shoudl be updated
yvanzo
where does that dependabot PR comes from?
reosarevok
Magic
CatQuest
oh no.
but. see Clarke's law
BrainzGit
[mb-solr] yvanzo closed pull request #35 (masterā¦dependabot/maven/mb-solr/org.apache.solr-solr-core-8.4.0): Bump solr-core from 7.7.2 to 8.4.0 in /mb-solr https://github.com/metabrainz/mb-solr/pull/35