User Details
- User Since
- Oct 4 2016, 5:18 PM (363 w, 4 d)
- Availability
- Available
- LDAP User
- Pmiazga
- MediaWiki User
- PMiazga (WMF) [ Global Accounts ]
Wed, Sep 20
Mon, Sep 18
Thu, Sep 14
I pushed the proposed change marked as DNM - @Dreamy_Jazz please let me know if this is what we're looking for. I haven't tested it yet, other than just running tests locally.
In c) I meant to skip adding this row entirely, and not add anything other. Yes, sorry, I messed up when copying/pasting. I didn't know is it safe to insert data to other table in such case as I don't know the big picture of what CheckUser is doing.
I see four possible solutions here:
So after investigating the code - We have a RecentChange entry, that contains information about the change in our system. RecentChange has an attribute rc_logid -> which is the log entry associated with given change. It can be 0 -> no log entry set, or a integer -> then it's a foreign_key to logging table.
Wed, Sep 13
@CDanis could you elaborate a little bit on this one? What do you mean "force a distributed tracing" ?
Tue, Sep 12
I found another log statement exactly from the same line. The previous error comes from fixStuckGlobalRename but the one I found comes from SpamBlacklist: https://logstash.wikimedia.org/app/dashboards#/view/c7013c90-a487-11ec-be91-b3435f0c0c49?_g=h@53fc073&_a=h@8974712 and was triggered on EditPage.
We went through a set of reviews and I'm expecting this work to be merged and this ticket to be closed this week.
Mon, Sep 11
Fri, Sep 8
Thu, Sep 7
Today on codemob we decided to move Telemetry class to includes/libs folder and make it generic. But when doing that, I found that the Telemetry cannot be global singleton, as it uses the MediaWiki config: https://github.com/wikimedia/mediawiki/blob/5405fdccfcb7fec8c0fd9b9c9c2a73ee18d98127/includes/http/Telemetry.php#L60
Fri, Sep 1
I cannot reproduce it anymore nor I don't see any similar logs. This error happened twice on on 2023-08-10 after each command:
Thu, Aug 31
Sorry for a bit of silence in this ticket, Recently I focused a little bit more on the T344926 issue which caused us lots of trouble due to layering issues (RESTBagOStuff and MultiHttpClient are part of general libs but Telemetry is MediaWiki specific).
We spoke about those changes today on Codemob and we agreed on:
Wed, Aug 30
It's pretty straightforward: https://gerrit.wikimedia.org/r/953689 but I agree - I don't like it as it introduces the layering issue - the RESTBagOStuff shouldn't know anything about Telemetry/Tracing - it's the HTTPClient (whatever client we use) responsibility, not the RESTBagOStuff.
After a pairing session with @DAlangi_WMF we decided that the best way to tackle this :
Tue, Aug 29
This is caused by MultiHttpClient using raw curl_*() calls instead HttpRequestFactory to get the HTTP client. On Prod env sessions use kask-session object cache, which uses RESTBagOStuff. The RESTBagOStuff could use a specific HTTP client - but we do not specify one via config (https://github.com/wikimedia/operations-mediawiki-config/blob/811b3dad11ea1cb629e06f71d94ab4e7208ccdfd/wmf-config/CommonSettings.php#L596C18-L596C3), therefore it fallback to default MultiHttpClient library to send requests (https://github.com/wikimedia/mediawiki/blob/f071c22a9a3e7e399dcf3256c96a952f15291a69/includes/libs/objectcache/RESTBagOStuff.php#L149). I also noticed it can support only MultiHttpClient and we cannot pass anything that extends MWHttpRequest which supports telemetry headers.
Mon, Aug 28
T344926 is a standalone ticket as it's an existing issue. From a quick check, sessions can use RESTBagOStuff to store/retrieve session data. When setting up a RESTBagOStuff we can specify a custom HTTP client, or it will use MultiHttpClient by default.
Aug 22 2023
For quick hacking I'm going to use the OpenTelemetry monorepo - https://github.com/open-telemetry/opentelemetry-php as the one from mszabo (https://github.com/mszabo-wikia/opentelemetry-php) seems a bit outdated.
Aug 21 2023
@Dreamy_Jazz - I quickly checked this code and I found that this is caused by this line
Adding Content-Transform-Team as they are the owners of Proton service. If there are any questions regarding this change I'm happy to help.
I see two tickets here, one to add tracing headers to the response (same as X-Request-ID), and second ticket to modify the extension to show additional fields.
@CDanis Can you confirm that you see traces on prod ?
Aug 17 2023
Recently @daniel raised a very good point about the performance of each solution, and whether it is faster to do instanceof (as it may have to traverse the inheritance tree) instead of calling property_exists() or even maybe trying to switch to $node->value ?? checks. I developed a super simple benchmark to verify which option would be the best pick.
Aug 16 2023
I'll abandon those.
I wouldn't worry about the function call overhead, as it's only a couple extra ops - and IMHO it's more a micro-optimization that we wouldn't be able to notice in the runtime. And I hope that in such cases compiler could optimize the code by just fetching the variable instead of doing a function call. Some languages already do that.
Aug 14 2023
It has to be something related to the CI configs, I'll look for someone who could help me reproduce this problem locally. I followed @Jdforrester-WMF advice and I loaded a specific set of extensions
wfLoadExtension('EventBus'); wfLoadExtension('EventLogging'); wfLoadExtension('EventStreamConfig'); wfLoadExtension( 'WikimediaMessages' ); wfLoadExtension( 'WikiLambda' );
After a bit of research and thinking about this. There are couple of possible ways of getting rid of the tech debt:
Aug 10 2023
@Jdforrester-WMF - can you link me to the tests that fail?
Could be, I didn't have the EventBus extension locally and didn't test it. But yesterday I started working on EventBus patch too, I'll have it ready today
Aug 9 2023
My understanding is that JobRunner uses overrideRequestId() with a null to reset the RequestId - but then after the reset - getting the id will try to get the ID from headers again, and if not present it will regenerate it.
I'll look into it
Thank you for your cooperation in this matter. Ticket closed.
Aug 7 2023
as @TheDJ says - Proton - our PDF renderer disables the Javascript when rendering the page: https://github.com/wikimedia/mediawiki-services-chromium-render/blob/76161ba764e28e0f4f494d903d41d875a64481e6/lib/renderer.js#L157
The current PDF renderer (Proton) provides a way to render Desktop and Mobile versions of PDF article. This is doable by asking Proton to render mobile version of article - which will make fonts much bigger (if we render a full a4 page with the regular font on a mobile device - the text is not readable). IMHO it would partially solve the problem as we would have a way to render a PDF with much bigger fonts for people who are visually impaired.
The current PDF renderer provides two types of output it can render a regular PDF and a Mobile Version of PDF which is much easier to read on mobile devices.
The output of the PDF renderer is cached only for 10 minutes to prevent mass rendering of the same article/regenerating the same content. PDFs are generated by a standalone service called Proton, and the implementation from the beginning didn't listen to purge events.
Currently, the rendered output of "Download as PDF" is cached on Varnish for 10 minutes. I don't think we have a place to store PDF files. Probably, this ticket refers to an old combination of Collection + electron-renderer which is not supported any more.
I'll close this ticket as it refers to a combination of old Collection extension and most likely the electron-render renderer. Right now we use https://www.mediawiki.org/wiki/Proton to generate PDFs and links.
"Download as PDF" uses a Chromium headless browser to save the generated MediaWiki page as PDF. The result is identical to going to the wiki page and hitting print, and then "Destination: Save as PDF". Because the Wiki page does not contain a list of contributors, it's not present in the PDF file.
@Krinkle had a pretty good question regarding the wgAllowExternalReqID guard.
Jul 28 2023
Jul 21 2023
Yesterday I confirmed with @Vgutierrez and @daniel that instead of building/creating the etag, we can just passthrough the LastModified - which btw is a better way. I'm going to update this phab ticket to reflect the current state.