Portal stats were updated on Oct 19, 2017:
Portal translations were updated on Oct 19, 2017
As the errors have gone away over time, I'll close out this ticket; mostly because it's not happening on our MediaWiki site and/or within CirrusSearch.
Unfortunate, but I agree with you, @TJones, this ticket is now moved.
I've scheduled a meeting for Wednesday, Oct 25. If you'd like to attend and you don't have a calendar invite, please let me know.
This seems like a good topic for a blog post, with a title along the lines of "So -happy to meet you."
Sounds like it'd be a great blog post, @TJones! :)
After we switch to node.js, we won't have this issue any more. We'll check again after the conversion as detailed here: T174103
This error is still happening, but the amount of events is less than 100 in the last 30 days; not super urgent.
We should still take a look at this - as it is nice to know when things fail.
Moving this to later, as we just don't have time for this right now and Analytics is still working on their portion of this type of work.
Once we're done with GC on WDQS, let's see if this is still needed and/or still effecting latency.
Hey @brion - is there still anything to be done on this task? If nothing, I'd like to close it or at least take off our board. Thanks!
Let's see if we can look at this issue, this quarter, @Jdrewniak, when you have spare time from the Portal automation tasks.
We typically only make sure that we're compatible with Core and nothing else, but we'll need to look at this and edit the wiki page as well.
Marking as stalled...not sure if any movement has been occurring on this.
I'll set up a meeting to go over the concept and details of this ticket and functionality.
Wed, Oct 18
Thanks, @dcausse, I've moved it to up next.
Sounds like a plan — let it run for a bit with increased logging and see if we see more of these errors. Otherwise, we can go ahead and close this out.
Does this block anything or is it just annoying?
Tue, Oct 17
Ah...I see the conversation now (where this ticket came from): https://en.wikipedia.org/w/index.php?title=Template_talk:Maplink&oldid=805751717
Hey @Gareth - can you give us more details and specific links on how/where this is happening?
@Pnorman is this something you can take a look at?
Let's scheduled a meeting to go over responsibilities for doing this work.
We could add in an exclusion filter, but we're not sure that is the best way to do this. Maybe the Readers-Community-Engagement can help determine what to do here. Maybe @CKoerner_WMF can help with the community conversation.
This isn't on our mediawiki site and most likely not related to CirrusSearch.
Moving to later, as we won't be able to get to this anytime soon. but we'll need it if we want to do new things with the translation server.
@mpopov - is this still needed?
We'll finish this after the rolling restart of servers happen...a few things yet to be done (security patch, etc).
We might want to do this test in French, as we have a few people that know that language to be able to help with translations and PII review.
This is still blocked on a merge...waiting.
We need someone with admin rights on this wiki in order to fix this. Moving this to the backlog until someone from rowiki can help — @AdiJapan and / or @XXN ?
This is fairly tricky and no obvious solution right now. We might want to wait for the next version of Logstash.
We'll get start this next week on Monday.
This will happen next week, after the test is completed.
This test can be run at the same time as other tests, as long as we get bucketing separated.
I've been testing this out...and I'm not sure why some work on Wikipedia and some work on Wikivoyage, but not both.
Mon, Oct 16
With today's merging of the code for adding namespaces to Bengali Wikisource, I think we've done everything that the community has wanted us to do for this ticket and moving it to the done column.
Looks nice @chelsyx -- here's my notes:
Yup, this is fine
- The do not show same article to same user, ever, has the requirement that it only works for a logged in user.... With the 2 day timeout that should also take more than a year.
This is good, and we shouldn't add in a bunch of JS that would be slowing down every page for anon users.
- Anonymous opt out is also on a best effort basis, the information is stored in local storage same as the timeout for how long until we can show a survey again. Logged in users have their opt out tracked on the backend which has stronger guarantees.
One thing i'm indecisive on, this new version now requires logged in and anonymous users to make an api request before the survey is shown to them. That could be a reasonably large number of new api requests. I don't think it's problematic, but if others do i could rework things so only logged in users have to make the api request.
Could we run a test on this for a day or two and see what the servers do? If we think it'll be an issue, let's only do the api request for logged in users.
Hello @Base - I've setup a meeting tomorrow to talk with our Legal team about this issue. I hope we can have a response to this issue soon.
@Yurik - could you expand on how this could be fixed with 'a few lines of code'?
Sun, Oct 15
@Sabas88, there has been no movement on this issue, unfortunately.
Fri, Oct 13
It looks like @dcausse will be able to do the re-indexing after next week's train deployment and because we really don't want to start the re-indexing on a Friday, the earliest we'd be able to do it is Monday, Oct 23rd.
Very nicely done, @TJones!
This is actually deployed in production now: http://discovery.wmflabs.org/metrics/#mobile_events (not only on beta)