- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 13 2019
Aug 12 2019
Aug 9 2019
Aug 8 2019
I don't want to expose externally what exactly our internal uris looks like, so the preq fix should be enough to achieev the goal of this.
Fixed and deployed. Resolving.
Aug 7 2019
Untagging core platform team inbox since the ticket is already categorized.
To completely roll out any frontend caching, I've repeated the experiment from inside the production cluster with curl, same result - first request - reproducible, second request - not reproducible. However, I could only reproduce on wmdebug hosts. Trying to randomly query production hosts doesn't reproduce.
@Krinkle checkd again. I can both reproduce and not reproduce with a 200.
@Krinkle hm, ok, now I can reproduce, but it's interesting.
In T229379#5398334, @Shizhao wrote:在T229379#5398056中,@Viztor写道:In T229379#5398021, @Pchelolo wrote:Hm. Trying to open https://zh.wikipedia.org/wiki/首页 both logged in, logged out and bypassing Varnishes gives me a normal page now while opening https://zh.wikipedia.org/wiki/Wikipedia:首页 gives the main page. Verified that served by HHVM. Is this still reproducible for others?
Appear to be correct after several tests here as well.
I am still able to reproduce this problem
Aug 6 2019
Hm. Trying to open https://zh.wikipedia.org/wiki/首页 both logged in, logged out and bypassing Varnishes gives me a normal page now while opening https://zh.wikipedia.org/wiki/Wikipedia:首页 gives the main page. Verified that served by HHVM. Is this still reproducible for others?
Checked again, now it works as expected. Resolving.
Checked the logs. The error indeed has disappeared.
Aug 5 2019
Could we instead get rid of the EventBus::TYPE_* stuff altogether, and just use per-stream config? I'm not sure I fully understand the reasoning behind the different TYPEs.
Ye, we first need to deploy https://gerrit.wikimedia.org/r/c/mediawiki/services/restbase/deploy/+/521572
As I understand, MCS implementation for this is completed and we now need to add it to RESTBase.
Given that we're quite confident in eventgate now as we've transitioned all the kafka-main mediawiki events to it with no issues, and a fairly limited difference between eventbus and eventgate, I propose to do a fairly quick transition. 3 steps should be enough.
Clearly I need to figure out a single Kibana query that shows all mobileapps errors.
We have not observed this problem in production.
I don't think we will do it since there was no activity in 5 years after filing this task.
It's not that I want this or that there's any use case. ssastry and I were investigating in T161546 whether TemplateStyles would make that task obsolete. If you read that task, maybe it will make sense.
Not necessarily. What we did was to duplicate the entries with optional parameters and use YAML references to avoid copy-pasting the whole definition. See https://github.com/wikimedia/restbase/blob/master/v1/talk.yaml#L116 for an example.
Service-checker supports swagger 3 definitions. Do you have any more info about what was in complained about?
I've created subtasks for Mobile-Content-Service and Mathoid . Graphoid is surprisingly ok regarding logging to logstash. Since the individual subtasks were assigned to appropriate components CPT is not responcible for, I consider this task to be done.
Is this done and can be resolved? There doesn't seem to be a mathoid installation on scb any longer
One thing that occurs to me is that if resource_change events are emitted at the same time for both mobile-sections(-lead) and summary on page edit, and this depends on mobile-sections-lead, we'll have set up a race.
Aug 2 2019
I believe that the inconsistency in the title validity checking and title creation is the root cause of this, but it's a larger issue. Filed T229705
A bit of investigation has found a deeper issue.
Seems like the above patch has not fixed it. Both repeating the API request and trying to check links to se: results in a different exception now:
@Mvolz Please do git pull in root vagrant directory and run vagrant provision again. You need to have this commit https://gerrit.wikimedia.org/r/c/mediawiki/vagrant/+/525646
Aug 1 2019
Ok, I went through kafka stream and this is what graphoid is calling in terms of MW API:
@Milimetric I believe graphoid will not go via varnish, but directly to an app server, so no surprise you didn't find the request.
Report written. Please reopen if it's not sufficient.