Ah sorry. Here is the public key ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF66vmTGSCShUC1HkopdFG8dtfPFOJQz+P6PVRypvDqV derenrich@wmf3489

I think we've decided to move ahead with merging @egardner's most recent patch (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaCustomizations/+/1312731).

• Latency/Load. I tried to re-create the TextExtracts call in question and profile it. It seems on a warmed up server, a latency of 1.05s will not be rare (Excimer profile; details in CR comment). Existing traffic (Grafana: MediaWiki Action API) observes a p95 of 1.0s and a p90 between 200-400ms, but it's hard to predict what the distribution will be like given this is based on a different traffic source. In any event, unlike canonical pageview URLs, this new endpoint will only be used by Discord and so should expect a much lower CDN cache hit rate. Both because nobody is warming it up and because the cache needs to be short to ensure edits propagate without a dedicated purge pipeline (e.g. 5min or max 1h, based on our other MW REST APIs that return user-generated content). This is separate from how long Discord promise/claim to cache it on their end. We should document what load we expect to add to the k8s-mw-api-ext cluster, and confirm this with SRE, with a documented roll-back plan if load exceeds expectations for any unanticipated reason.

hi. i'm really sorry but this was already done at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaCustomizations/+/1307873/5/src/Discord/DiscordHookHandler.php and this ticket was just not properly closed. i think it was a leftover duplicate that had been placed into the graveryard but not fully marked as closed. my apologies for wasting your time. thank you for your contribution though.

I think there's a misunderstanding. I suggested moving the wprov-strip logic from WikimediaEvents to core. That means we continue to strip as today. No change, no loss, just moving the code. The mediawiki.page.ready module is a fine place to stash it for now. Easy to move around later, when it doesn't define new APIs/exports.

We generally define JS APIs on a namespace owned by and named after the module name, or export them from the module object.

i'm curious why this was closed as invalid. are there workarounds?

i vouch for her

Amazing. Thank you so much.

thanks for the reply. i think first it would be helpful to know what the current limits are. i've been given conflicting information. not being able to enforce the limit means our users sometimes sit for 11 seconds with nothing happening.

given the recently announced increase in rate limiting i think this ticket is more urgent

here is the request in full

i tried swapping from polka to express as my server and that had no effect. really unsure how this could be on my side but it seems unlikely it isn't given no other services are impacted.

i've had trouble testing these kinds of things myself. optimally we'd mock out an item?

i restored the sandbox to a state where it demonstrates the bug

I think it won't reproduce because the contents of the sandbox item has
changed.

stars collected is done
fun fact collected is done
Levels finished is done
total plays is done

ok no worries and no rush. this isn't blocking but I was hoping to have a sense of this direction would work (and how the process works). it sounds like much of that is still up in the air.

Is there something more you need from me here? What is the typical turn-around time for requests like this?

the model is still being evaluated so as such we do not have a specific product that is going to make requests. likely the requests would come from the wide-internet (since FA would want to integrate it into services running on toolforge or roblox).

i did this

I think using the python library tqdm causes it.

I think it's being caused by programs that print in weird ways (e.g. using terminal escapes). I understand the desire to not just blindly ignore these exceptions this but this issue has been causing issues for me for over a year. maybe we can just emit a dummy date and a warning about the parse error. i would've just forwarded it with None for the date but it seems downstream consumers aren't robust to it being None

I made a small patch to deal with this. I would push it to. see the attached patch.