Page MenuHomePhabricator
Feed Advanced Search

Yesterday

Arkanosis awarded T215042: Set up a hosted Matrix.org / Riot instance a Love token.
Mon, Apr 22, 9:43 PM · User-Tgr, Wikimedia-General-or-Unknown
Arkanosis awarded T193961: Set up Matrix.org homeserver on the Wikimedia Cloud VPS a Love token.
Mon, Apr 22, 9:39 PM · MediaWiki-Stakeholders-Group-Technical, Wikimedia-General-or-Unknown, User-Tgr
Arkanosis awarded T186061: Evaluate Matrix / Riot.im a Love token.
Mon, Apr 22, 9:35 PM · User-Tgr, Developer-Advocacy, Wikimedia-General-or-Unknown
Tgr added a comment to T221540: Move #tool-extjsonuploader to a subproject of #tools.

I don't see any way to do that, I guess you'd have to be a phab admin?

Mon, Apr 22, 6:41 PM · Project-Admins, Phabricator
Tgr updated the task description for T221540: Move #tool-extjsonuploader to a subproject of #tools.
Mon, Apr 22, 6:36 PM · Project-Admins, Phabricator
Tgr created T221535: Provide a "wiki farm" abstraction in MediaWiki core.
Mon, Apr 22, 7:07 AM · MediaWiki-Farmers, MediaWiki-Sites, MediaWiki-Configuration

Sun, Apr 21

Tgr committed rLTEUeb82ad8365e5: Fetch coverage data (authored by Tgr).
Fetch coverage data
Sun, Apr 21, 6:33 AM
Tgr created T221510: Provide list of repos with coverage information in machine-readable format.
Sun, Apr 21, 1:19 AM · Tool-extjsonuploader, Continuous-Integration-Config, Test-Coverage

Sat, Apr 20

Tgr added a parent task for T155155: Implement a way to view (extension) configuration options and its value on-wiki: T388: RfC: Graphical configuration interface.
Sat, Apr 20, 11:34 PM · MediaWiki-Configuration
Tgr added a subtask for T388: RfC: Graphical configuration interface: T155155: Implement a way to view (extension) configuration options and its value on-wiki.
Sat, Apr 20, 11:34 PM · TechCom-RFC
Tgr created T221509: Query "ManiphestTaskQuery" failed to return a value from getPagingValueMap() for column "rank"..
Sat, Apr 20, 10:52 PM · Phabricator
Tgr added a hashtag to Wikimedia-Technical-Conference-2018: #techconf2018.
Sat, Apr 20, 10:42 PM
Tgr committed rLTEU6134db2dbd0d: Convert to PSR-4, add standard boilerplates, add tests (authored by Tgr).
Convert to PSR-4, add standard boilerplates, add tests
Sat, Apr 20, 5:56 AM
Tgr added a comment to T74501: Need a way for trusted OAuth apps to make edits from blocked IPs.

OAuth is currently not resourced, but there's a team working on blocking tools so realistically you might have better chances for improving things from that direction. Autoblocks of Toolforge IPs probably should not happen, after all, it's sufficiently important and trusted infrastructure that it should only be blocked by someone who is conscious of what they are doing.

Sat, Apr 20, 3:10 AM · MediaWiki-extensions-OAuth
Tgr added a comment to T221041: Convert Parsoid to dependency injection.
The only point of connection might be adding $contentType="wikitext/1.0"/$resulttype="html/2.1.0" parameters to some top-level getParserService call, to keep the door open for backwards-incompatible changes to wikitext / etc in the future.
Sat, Apr 20, 3:04 AM · User-Daniel, Core Platform Team (Decoupling (CDP2)), Parsoid-PHP, Technical-Debt

Fri, Apr 19

Tgr added a comment to T221166: Session authentication in Parsoid REST API.

Individual endpoints, yeah. Session setup takes a nontrivial amount of time and most GET endpoints won't need it (the action API tends to mix public and private data, e.g. show redacted usernames if you have the permission to see them; in the REST API we probably don't want that as it makes responses uncacheable). I don't think it's hard, just an an extension point in Setup.php (pretty much everything else is loaded by that point), but something to think about.

Fri, Apr 19, 8:49 PM
Tgr added a comment to T221176: GET /_version/.

The deeper problem here is what versioning even means for an API that's inside MediaWiki. Is it reliable if it doesn't include the MediaWiki core, library, extension etc. versions? Is it still useful if it does include them?

Fri, Apr 19, 5:26 PM
Tgr added a comment to T221176: GET /_version/.

The current API sort-of equivalent of Special:Version is action=query&meta=siteinfo. That's probably something we want to port to REST; not sure whether it's the right place for finding out the version of specific API endpoints as it will be rather large. Something like an OPTION request to that endpoint or a /version/<normal endpoint URL> might be easier on clients. Soemthing to consider for the routing handler interface.

Fri, Apr 19, 5:22 PM
Tgr added a comment to T221167: Handle Gzip encoding for all endpoint in Parsoid REST API.

See OutputHandler::handleGzip().

Fri, Apr 19, 5:13 PM
Tgr added a comment to T221162: REST API Rate Limiting.

Some related tasks:

Fri, Apr 19, 5:08 PM
Tgr added a comment to T221162: REST API Rate Limiting.

MediaWiki rate limiting is based on user authentication, and often happens deep in the application (for example there are different rate limits for rendering a thumbnail in a standard size and a nonstandard one; the API does not know what are the standard sizes) and is only communicated to the controller in the form of error messages.

Fri, Apr 19, 5:04 PM
Tgr updated subscribers of T221161: API keys.

There was a push for API keys as a prerequisite for some vague monetization ideas when the previous ED was trying to reshuffle things; that was opposed vigorously and eventually got dropped. I don't remember the details, I think @bd808 was asked to work on it since he was doing API analytics at the time, so maybe he has pointers to the old discussions.

Fri, Apr 19, 4:58 PM
Tgr added a comment to T221166: Session authentication in Parsoid REST API.

I imagine we'll still call Setup.php and that takes care of authentication. OTOH there should probably be a way for API endpoints to declare themselves sessionless.

Fri, Apr 19, 4:53 PM
Tgr added a comment to T221173: Resolve domains in path of endpoints for Parsoid REST API.

All MediaWiki appservers contain the code and configuration for all wikis and select which one to apply based on the Host header. In theory that logic could be amended to handle Parsoid REST URLs with domains in them, but it would be confusing, would add extra complexity for no good reason, and would not work for third parties (wikifarm management is not standardized, every farm handles multi-wiki configuration in their own way). Also makes cookie-based authentication complicated (if not impossible). Changing what URLs RESTBase and the MediaWiki virtual REST service send to seems far simpler.

Fri, Apr 19, 4:50 PM
Tgr awarded T200739: Upgrade to Gerrit 2.16.7 a Orange Medal token.
Fri, Apr 19, 6:14 AM · Release-Engineering-Team (Backlog), Patch-For-Review, Gerrit
Tgr committed rLTEU28812fb9b90b: Convert to PSR-4, add standard boilerplates, add tests (authored by Tgr).
Convert to PSR-4, add standard boilerplates, add tests
Fri, Apr 19, 5:57 AM
Tgr added a comment to T221041: Convert Parsoid to dependency injection.

If however Parsoid is a library used by core, this should not even be needed. Code that follows a DI design generally has no need to, and in fact should not, have any use for or knowledge of a DI framework.

Fri, Apr 19, 3:26 AM · User-Daniel, Core Platform Team (Decoupling (CDP2)), Parsoid-PHP, Technical-Debt

Thu, Apr 18

Tgr committed rLTEU9067c948219e: Convert to PSR-4, add standard boilerplates (authored by Tgr).
Convert to PSR-4, add standard boilerplates
Thu, Apr 18, 9:00 PM
Tgr updated the image for Tool-extjsonuploader from F28697613: profile to F28697623: profile.
Thu, Apr 18, 5:49 PM
Tgr set the image for Tool-extjsonuploader to F28697613: profile.
Thu, Apr 18, 5:48 PM
Tgr edited Description on Tool-extjsonuploader.
Thu, Apr 18, 5:43 PM
Tgr created Tool-extjsonuploader.
Thu, Apr 18, 5:43 PM

Wed, Apr 17

Tgr added a comment to T216308: RFC Process: 2019 amendments.

Do we want to allow for closing an RFC in this stage?

Wed, Apr 17, 9:21 PM · TechCom-RFC, TechCom
Tgr added a comment to T221158: Parsoid REST API in PHP.

Any objection to creating a MediaWiki-REST-API Phabricator project for this?

Wed, Apr 17, 4:25 AM · Parsoid-PHP, Services (watching), Core Platform Team, Goal, MediaWiki-Parser

Tue, Apr 16

Tgr added a comment to T220657: Establish Architecture Principles as a policy.

What about extensions bundled with MediaWiki in the release tarballs, but not deployed on Wikimedia servers? Usually we require the same standards for those, as that's what users will expect.

Tue, Apr 16, 1:28 AM · TechCom-RFC, TechCom

Mon, Apr 15

Tgr added a comment to T220893: API for listing authors of an article.

Duh, not sure how I missed that. Thanks.

Mon, Apr 15, 9:56 PM · MediaWiki-API, MediaWiki-History-and-Diffs
Tgr added a comment to T155395: Create documentation about the proper use of the dependency injection infrastructure in MediaWiki .

Related: document proper use of dependency injection in MediaWiki libraries (e.g. T221041: Convert Parsoid to dependency injection).

Mon, Apr 15, 9:54 PM · TechCom, MediaWiki-Documentation, MediaWiki-General-or-Unknown, Documentation, User-Daniel
Tgr added a comment to T220657: Establish Architecture Principles as a policy.

What do you think?

Mon, Apr 15, 9:51 PM · TechCom-RFC, TechCom
Tgr added a comment to T214321: Create a value-only interface alternative to the File class.

exists() seems reasonable for a FileIdentity class (although remote repos make it more complex, but in some sense that issue exists with Title/PageIdentity as well). getUrl() (and getDescriptionUrl() which is fairly different in terms of systems involved) should live in the Repo as that's the class that deals with the local / shared DB / API split (although caching the results in a value object like FileIdentity does not seem unreasonable). allowInlineDisplay() (aka canRender()), mustRender() and isVectorized() should be in MediaHandler (they mostly are, we just need to deprecate handlerless files). getWidth() should probably be moved to a FileMetadata value object (where FileIdentity represents DB state and FileMetadata represents the file on disk, although in practice metadata is also cached in the DB). transform() probably merits its own service.

Mon, Apr 15, 9:40 PM · Core Platform Team (Decoupling (CDP2)), Core Platform Team Kanban, MediaWiki-File-management, Multimedia, Commons
Tgr added a comment to T220939: Display extension test coverage in infobox.

I would keep tools mostly single-purpose: have the coverage tool expose the data as a JSON API (where API probably just means writing it to a JSON file and making it accessible) and have the extjsonuploader tool deal with pushing it on-wiki along with the other extension data.

Mon, Apr 15, 9:22 PM · User-Tgr, Code-Health, Test-Coverage
Tgr created T221041: Convert Parsoid to dependency injection.
Mon, Apr 15, 8:32 PM · User-Daniel, Core Platform Team (Decoupling (CDP2)), Parsoid-PHP, Technical-Debt
Tgr updated the task description for T133452: Create temporary accounts for anonymous editors.
Mon, Apr 15, 6:45 PM · TechCom-RFC, Core Platform Team (Security, stability, performance and scalability (TEC1)), Core Platform Team Backlog (Later), User-Tgr, WMF-Legal, Privacy, MediaWiki-Authentication-and-authorization
Tgr added a comment to T165795: Ldap auth extension vs. ldap vs. username Case.

statsd typically does not allow you to slice the data per wiki. Logstash says there were 60 logins in the last 7 days, which is trivial (unless you are worried about the potential DoS angle).

Mon, Apr 15, 6:34 PM · Patch-For-Review, cloud-services-team (Kanban), wikitech.wikimedia.org, MediaWiki-extensions-LdapAuthentication
Tgr committed rLTEUac441de1190d: Initial commit (authored by tools.extjsonuploader <tools.extjsonuploader@tools-sgebastion-07.tools.eqiad.wmflabs>).
Initial commit
Mon, Apr 15, 9:44 AM
Tgr renamed T220330: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant from GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant for GSOC 2019 to GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant.
Mon, Apr 15, 6:59 AM · Google-Summer-of-Code (2019)
Tgr added a comment to T100294: [EPIC] Encourage developers to increase code coverage.

Some ideas I have been playing with: T220939: Display extension test coverage in infobox, T220938: Display per-line test coverage during code review.

Mon, Apr 15, 6:57 AM · Release-Engineering-Team, WMF-deploy-2015-06-30_(1.26wmf12), Epic
Tgr added a project to T220939: Display extension test coverage in infobox: User-Tgr.
Mon, Apr 15, 6:56 AM · User-Tgr, Code-Health, Test-Coverage
Tgr added a comment to T182749: Track test code coverage long term.

Is there / will there be an API to access this data?
One potential use case would be T220939: Display extension test coverage in infobox.

Mon, Apr 15, 6:55 AM · Core Platform Team (Code Health (TEC13)), Core Platform Team Backlog (Later), Test-Coverage, MediaWiki-Core-Testing
Tgr created T220939: Display extension test coverage in infobox.
Mon, Apr 15, 6:54 AM · User-Tgr, Code-Health, Test-Coverage
Tgr created T220938: Display per-line test coverage during code review.
Mon, Apr 15, 6:48 AM · Test-Coverage, Code-Health, Upstream, Gerrit
Tgr assigned T220330: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant to Hjhimanshu.
Mon, Apr 15, 6:40 AM · Google-Summer-of-Code (2019)

Sun, Apr 14

Tgr added a comment to T29629: Mechanism for crediting external authors of a page.

Theoretically you could do it with a hand-crafted import file...

Sun, Apr 14, 10:25 PM · MediaWiki-Export-or-Import, MediaWiki-History-and-Diffs, MediaWiki-extension-requests

Sat, Apr 13

Tgr awarded Blog Post: Evaluating Element Timing for Images a Like token.
Sat, Apr 13, 11:19 PM
Tgr added a comment to T4994: Automatically generated count and list of contributors to an article (authorship tracking).

See also T220893: API for listing authors of an article which would accomplish this task as stated in the description (but not really stated the purpose of determining the principal author).

Sat, Apr 13, 11:12 PM · MediaWiki-History-and-Diffs
Tgr updated the task description for T220893: API for listing authors of an article.
Sat, Apr 13, 11:11 PM · MediaWiki-API, MediaWiki-History-and-Diffs
Tgr added a comment to T220893: API for listing authors of an article.

I imagine this would require a (page, actor) index on revision. action=credit is disabled on Wikimedia projects because without such an index WikiPage::getContributors() is too expensive.

Sat, Apr 13, 11:10 PM · MediaWiki-API, MediaWiki-History-and-Diffs
Tgr created T220893: API for listing authors of an article.
Sat, Apr 13, 11:07 PM · MediaWiki-API, MediaWiki-History-and-Diffs
Tgr added a comment to T220657: Establish Architecture Principles as a policy.

It would be useful to add something about who is expected to know / enforce the policy. This is a pretty heavy technical document; throwing it at new contributors is a good way of making them not contributors anymore. IMO the point by which one is expected to read and understand the document is getting +2; reviewers should be expect to act as human interface to the policy and explain specific problems to patch authors without making them read four pages of dense technical jargon. That might be obvious but IMO worth spelling out.

Sat, Apr 13, 10:59 PM · TechCom-RFC, TechCom
Tgr added a comment to T220657: Establish Architecture Principles as a policy.

I feel this needs to be a "SHOULD". There are certainly situations where it is not possible to "avoid" wikitext entirely.

Sat, Apr 13, 10:55 PM · TechCom-RFC, TechCom
Tgr added a comment to T4994: Automatically generated count and list of contributors to an article (authorship tracking).

This task is a bit unfocused. Most of the discussion is about blame maps so maybe merge into T2639: [Epic] Add feature annotate/blame command, to indicate who last changed each line / word?

Sat, Apr 13, 10:43 PM · MediaWiki-History-and-Diffs
Tgr added a comment to T29629: Mechanism for crediting external authors of a page.

Is this a duplicate of T9240: Usernames in history of imported pages should refer to original wiki (which is now fixed)?

Sat, Apr 13, 10:37 PM · MediaWiki-Export-or-Import, MediaWiki-History-and-Diffs, MediaWiki-extension-requests
Tgr added a comment to T220779: Add test to check existence of action- messages.

Actions are a fuzzy concept in MediaWiki (see e.g. T212345: Authorization checks have $action parameter, but accept a user right). In one sense, and action is something that has an Action subclass and can be triggered via the action= URL parameter, and that's a small subset of rights. (Well, not technically a subset, there are actions like history which do not have an associated user right.) But the action- messages are used in permission error messages, and in the future we'll probably want to move towards always having error messages (T180888: All permission checks should be able to return a custom error message) as it is hard for the extension author to predict when they will be necessary, so having these messages seems like a step in the right direction. There will be exceptions, but it is always better to err on the harmless side.

Sat, Apr 13, 9:54 PM · I18n, MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-Core-Testing
Tgr added a comment to T220825: After nominating a file on Wikipedia for deletion, the page sections show a duplicate of themselves.

The Commons templates on the other hand are not shown, so it seems as if the local description page was fetched when the software tried to get the Commons one.

Sat, Apr 13, 2:23 AM · MediaWiki-File-management, Commons, Multimedia

Fri, Apr 12

Tgr updated subscribers of T382: RfC: Server-side Javascript error logging.

@phuedx can you comment? You probably have a better grasp of the current status.

Fri, Apr 12, 8:46 PM · Epic, TechCom-RFC
Tgr added a comment to T133452: Create temporary accounts for anonymous editors.

I think the more interesting question is when anonymous user accounts should be created. We cannot create them for visits which don't result in a page save attempt or similar, for obvious scaling reasons. If we create them on write (ie. when an actor ID needs to be inserted somewhere), the user will be detached from their contribution if the user agent does not persist the session (e.g. browsing with cookies disabled) without us being able to detect it beforehand and warn them. If we create them just before write (e.g. whenever a CSRF token is obtained, like the user opening the edit form), that means doing stateful work on GET.

Fri, Apr 12, 7:08 PM · TechCom-RFC, Core Platform Team (Security, stability, performance and scalability (TEC1)), Core Platform Team Backlog (Later), User-Tgr, WMF-Legal, Privacy, MediaWiki-Authentication-and-authorization
Tgr committed rMSCR8cc96e7eaf33: Make timeout handling more robust (authored by Tgr).
Make timeout handling more robust
Fri, Apr 12, 6:55 PM
Tgr updated subscribers of T499: Create error logging JS module.

A very minimal error handler has been added to core: mediawiki.errorLogger.js. It doesn't do anything beyond pushing exceptions on an mw.track channel.
The rest was written as Extension:Sentry which uses the Sentry client library to report those exceptions. This was done four years ago so the frontend code is very outdated. We might or might not want to use the Sentry library anyway - it can canonicalize stack traces which is nice, but initially we don't need stack traces (and can't have useful traces anyway due to lack of source map support in ResourceLoader), and it is fairly large. @phuedx or the Reading Web team are probably better people to coordinate with on this.

Fri, Apr 12, 5:41 AM · Sentry
Tgr added a comment to T382: RfC: Server-side Javascript error logging.

@Milimetric cool! Not though that all this is very outdated and currently most of the work is not in MediaWiki. I wrote a more current summary in T217142#5103038.

Fri, Apr 12, 3:50 AM · Epic, TechCom-RFC
Tgr moved T217724: Investigate 2019-03-01 Proton incident from To Do to Code Review on the Reading-Infrastructure-Team-Backlog (Kanban) board.
Fri, Apr 12, 3:48 AM · Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Core Platform Team (Security, stability, performance and scalability (TEC1)), Proton
Tgr added a comment to T213505: RfC: OpenGraph descriptions in wiki pages.

Quick question: what's the plan for this from a product point of view? Is it slated for implementation soon? Knowing this will help us plan how/when to discuss.

Fri, Apr 12, 3:46 AM · MediaWiki-General-or-Unknown, TechCom-RFC, Reading-Infrastructure-Team-Backlog (Kanban)
Tgr committed rMSCR455159698c1a: Make timeout handling more robust (authored by Tgr).
Make timeout handling more robust
Fri, Apr 12, 3:28 AM
Tgr committed rMSCR08657232ce5c: Make timeout handling more robust (authored by Tgr).
Make timeout handling more robust
Fri, Apr 12, 3:14 AM
Tgr added a comment to T218395: Create RestrictionStore service.

PageIdentity refers to a page that exists; protecting non-existing pages is entirely meaningful. Also you need to deal with conterfactual state for permission checks. E.g. a permission check for moving a page into the MediaWiki namespace (which has a magic restriction) needs to check against the future state of the page. (This comes up elsewhere as well, e.g. permission checks for a content model change. Probably worth thinking about as a general issue.) So something like TitleValue seems more appropriate here.

Fri, Apr 12, 12:09 AM · Core Platform Team Kanban (Contractor - Ready), Core Platform Team (Decoupling (CDP2))
Tgr added a comment to T211488: Audit and sync INI settings as needed between HHVM and PHP 7 .
  • include_path in php's ini is still set to the value it had in the old times before we migrated to HHVM. I think it's irrelevant nowadays for all applications and can be removed. I think it's actually potentially harmful.
Fri, Apr 12, 12:03 AM · PHP 7.2 support, Patch-For-Review, Performance-Team (Radar), Operations

Thu, Apr 11

Tgr added a comment to T220648: Communications plan for Electron -> Proton switchover.

No date yet, some work is still pending. Probably about a month from now, unless someone has different plans.

Thu, Apr 11, 11:59 PM · User-Johan, Readers-Web-Backlog, Reading-Infrastructure-Team-Backlog (Kanban), Proton
Tgr renamed T220329: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant from GSoC Proposal 2019: Build statistics toolset to support WM-HU editor retention grant to GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant.
Thu, Apr 11, 5:31 PM · Google-Summer-of-Code (2019)
Tgr renamed T220330: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant from Proposal: Build statistics toolset to support WM-HU editor retention grant for GSOC 2019 to GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant for GSOC 2019.
Thu, Apr 11, 5:31 PM · Google-Summer-of-Code (2019)
Tgr renamed T220714: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant from Build statistics toolset to support WM-HU editor retention grant to GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant.
Thu, Apr 11, 5:31 PM · Google-Summer-of-Code (2019)
Tgr added a subtask for T218277: Build statistics toolset to support WM-HU editor retention grant: T220714: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant.
Thu, Apr 11, 5:30 PM · Technical-Tool-Request, Google-Summer-of-Code (2019), Outreach-Programs-Projects, User-Tgr
Tgr added a parent task for T220714: GSoC 2019 Proposal: Build statistics toolset to support WM-HU editor retention grant: T218277: Build statistics toolset to support WM-HU editor retention grant.
Thu, Apr 11, 5:30 PM · Google-Summer-of-Code (2019)
Tgr added a comment to T220720: Document what requires mediawiki-vendor required libraries.

The main complication is that we pin the entire dependency tree so most requires do not come from core or an extension directly but are a requirement for a requirement. And since those requirements change with every upgrade, and a library might be required by multiple things, it's quite hard to keep track even for just core why something is needed or whether it is still needed at all. This also makes it hard to verify that version requirements are met (T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present).

Thu, Apr 11, 5:17 PM · Patch-For-Review, Documentation, MediaWiki-Vendor
Tgr created T220719: Standardize return type hint spacing.
Thu, Apr 11, 4:57 PM · MediaWiki-Codesniffer, MediaWiki-General-or-Unknown
Tgr added a comment to T217724: Investigate 2019-03-01 Proton incident.

Thanks, I didn't realize firejail wraps the whole service, not just the render processes. Let's go with JS-only then.

Thu, Apr 11, 2:40 AM · Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Core Platform Team (Security, stability, performance and scalability (TEC1)), Proton
Tgr added a comment to T37247: content-holding <div> should only contain the page text.

Can someone clarify for me if this is why ParserOptions::setWrapOutputClass() no longer takes 'false' as an option (this being the only sane way I could find to disable the entire wrapper when running parser->parse on a thing)?

Thu, Apr 11, 1:16 AM · User-notice, User-Ryasmeen, MW-1.30-release-notes, Patch-For-Review, Parsoid, TemplateStyles, VisualEditor, StructuredDiscussions, Collaboration-Team-Triage, MediaWiki-Interface
Tgr added a comment to T217142: [WIP] [Proposal] Use the Kafka-Logstash logging infrastructure to log client-side errors.

To recap what was said at the meeting and in some earlier conversations, there are three independent work streams:

  • Capturing errors on the client side.
    • Extension:Sentry does this (it loads Raven.js, the old Sentry client on demand when an error happens) but the code is four years old now so probably should be updated to the current Sentry client, @sentry/browser (which might or might not be simple). The old code contained some awkwards workarounds, largely because Raven.js was a wrapper around TraceKit which was a valuable library with lots of hard-won compatibility logic for various browser quirks but very inflexible in how it expected to be used (e.g. it really did not expect to be loaded only after the error was thrown). Back then they were on the verge of removing it and rewriting Raven.js so that probably happened since then.
    • We could also write our own client. The benefit of using the official one is support for lots of browser quirks, including parsing of different stack trace renderings in different browsers (which could be reimplemented but it takes time). The benefit of a custom client is that it will probably end up being much smaller (@sentry/browser is 50K minified). Also stack traces are only useful if there are source maps, plus ResourceLoader client side caching would also have to be dealt with (probably also doable with source maps - see T90524 for details).
  • A pipeline for getting error logs to their destination.
    • In theory this could be a Sentry server. When I showed our traffic numbers to Sentry devs a few years ago they said a single beefy bare-metal server could probably take it (but their own traffic numbers were a bit below our worst case predictions so it was just a guess). But there's no guarantee and anyway we'd probably want decoupling and a standard pipeline for all events.
    • Using an EventLogging-ish process with a beacon endpoint being read into Kafka by varnishkafka, as described in this task (that was the old plan as well: T501). Problematic due to size limits (we'd have to drop stack traces at the minimum).
    • Using EventGate to send reports to Kafka, which seems the clear winner. With both this and the previous option, we'd want some kind of rate limiting in Kafka (Kafka itself scales well).
  • Storing/displaying the erros.
    • Sentry would be the nice option here (it has lots of features for supporting browsing, searching, displaying and managing errors) but it's a fair bit of work to package (unless we decide running third-party docker containers is acceptable now). Bonus is that it has clients for just about any programming language and we have plenty of systems (both WMF and community-maintained) where scaling is not a concern so we can just stick in a client and get error management for free. So probably a good long-term goal.
    • Just dumping the errors into logstash would probably get us decent searching and trend monitoring capabilities for free, so that seems the reasonable thing to do initially. (This was the old plan - T502.) Even if we use Sentry eventually, we might want to keep Logstash in the pipline for deduplication.
Thu, Apr 11, 12:55 AM · User-herron, Reading-Infrastructure-Team-Backlog, Wikimedia-Logstash

Wed, Apr 10

Tgr added a comment to T209295: [EPIC] Enable WebClientError on production.

FWIW the old plan for the Multimedia team (which was never resourced beyond the MVP level) was T382: RfC: Server-side Javascript error logging and the associated RfC, which is now very dated but might contain some useful information.

Wed, Apr 10, 11:19 PM · Epic, MobileFrontend (MobileFrontend and MinervaNeue architecture), Readers-Web-Backlog
Tgr merged task T77110: Push messages to logstash from JS into T502: Create WMF endpoint for error logging - part 2 (consumer).
Wed, Apr 10, 11:17 PM · MediaWiki-General-or-Unknown, JavaScript, Wikimedia-Logstash
Tgr merged T77110: Push messages to logstash from JS into T502: Create WMF endpoint for error logging - part 2 (consumer).
Wed, Apr 10, 11:17 PM · Sentry
Tgr added a comment to T77110: Push messages to logstash from JS.

Like most Mingle tasks this is mostly useless and was just created to track a phab ticket on a Mingle board. The useful part was T382: RfC: Server-side Javascript error logging and more specifically T502: Create WMF endpoint for error logging - part 2 (consumer).

Wed, Apr 10, 11:16 PM · MediaWiki-General-or-Unknown, JavaScript, Wikimedia-Logstash
Tgr added a comment to T210651: Switch all PDF render traffic to new Proton service.

How would the switch itself look? Do we want some kind of staggered rollout (or rollover, I guess) with only a fraction of the users switched at first? Or not worth the effort?

Wed, Apr 10, 7:46 PM · Reading-Infrastructure-Team-Backlog, Core Platform Team Backlog (Later), Services (next), Readers-Web-Backlog (Tracking), Proton
Tgr added a comment to T210651: Switch all PDF render traffic to new Proton service.
  • RESTBase adds optional parameters supported by Proton and not Electron

! In T210651#4936527, @Pchelolo wrote:

To achieve point 1, we need to

    • Refactor PDF module in RESTBase only to proxy traffic to Proton and remove the capability of split traffic, plus simplify the config.
  • See whether we would still need a js module for it, or it's possible to achieve the same result with a template-based module with no JS.
Wed, Apr 10, 7:45 PM · Reading-Infrastructure-Team-Backlog, Core Platform Team Backlog (Later), Services (next), Readers-Web-Backlog (Tracking), Proton
Tgr added a comment to T197862: Increase the CPU count for proton[12]00[12].

This is currently a subtask of T210651: Switch all PDF render traffic to new Proton service - does that mean it is seen as a blocker? If not, what's the expected impact / timeline?

Wed, Apr 10, 7:39 PM · Core Platform Team (Security, stability, performance and scalability (TEC1)), Core Platform Team Kanban (Done with CPT), Services (done), Reading-Infrastructure-Team-Backlog, Operations, Proton
Samat awarded T181315: Varnish HTTP response from app servers taking 160s (only 0.031s inside Apache) a Love token.
Wed, Apr 10, 7:38 PM · Performance-Team-notice, Patch-For-Review, Performance-Team (Radar), Traffic, Operations
Tgr added a parent task for T220648: Communications plan for Electron -> Proton switchover: T181084: [EPIC] Deploy the mediawiki-services-chromium-render service (Proton).
Wed, Apr 10, 7:36 PM · User-Johan, Readers-Web-Backlog, Reading-Infrastructure-Team-Backlog (Kanban), Proton
Tgr added a subtask for T181084: [EPIC] Deploy the mediawiki-services-chromium-render service (Proton): T220648: Communications plan for Electron -> Proton switchover.
Wed, Apr 10, 7:36 PM · Reading-Infrastructure-Team-Backlog, Readers-Web-Backlog, Readers-Web-Kanbanana-Board-Old, Proton, Epic
Tgr updated subscribers of T220648: Communications plan for Electron -> Proton switchover.

@ovasileva since you are the product owner for PDF rendering (which is really what the communication would be about), any thoughts on this?

Wed, Apr 10, 7:36 PM · User-Johan, Readers-Web-Backlog, Reading-Infrastructure-Team-Backlog (Kanban), Proton
Tgr created T220648: Communications plan for Electron -> Proton switchover.
Wed, Apr 10, 7:34 PM · User-Johan, Readers-Web-Backlog, Reading-Infrastructure-Team-Backlog (Kanban), Proton
Tgr added a comment to T208768: Create a PermissionManager service.

T220623: Unable to view certain pages on incubator.wikimedia.org (Fatal error: operator not supported) seems related.

Wed, Apr 10, 4:23 PM · Anti-Harassment, Core Platform Team Kanban (Contractor - Doing), Core Platform Team (Decoupling (CDP2)), Patch-For-Review, MediaWiki-Authentication-and-authorization, MediaWiki-User-management
Tgr added a comment to T209749: Allow privileged accounts to determine if an account has enrolled in 2FA.

There's no way to check someone's password without having them enter it, so if you want to turn this into a more generic account security check (which would presumably cover password policies + 2FA as there's not much else we can check - a check for not loading unsafe Javascript would be nice but probably not feasible) that'd probably have to be some kind of private log where the user can add an entry by reauthenticating.

Wed, Apr 10, 4:22 PM · Security, MediaWiki-extensions-OATHAuth, Trust-and-Safety

Tue, Apr 9

Tgr moved T213505: RfC: OpenGraph descriptions in wiki pages from Code Review to Blocked on the Reading-Infrastructure-Team-Backlog (Kanban) board.
Tue, Apr 9, 4:07 PM · MediaWiki-General-or-Unknown, TechCom-RFC, Reading-Infrastructure-Team-Backlog (Kanban)