I copied the page and the TextExtracts API request for my copy doesn't include the word "Edit". I don't know why the enwiki TextExtracts returns "...== Etymology and usageEdit ==...", weird.

@Jdlrobson The issue is still present, as described by @Spage in the description. (a sample API request is mentioned therein)

It looks like this issue applies to articles where the lead section is smaller than the requested number of characters. For example:

• The entirety of the lead section for [[Crepuscular]] is literally the single sentence, "Crepuscular animals are those that are active primarily during twilight (i.e., dawn and dusk)."
• If I issue a query with exsentences=2, or with exsentences=10, it still (correctly?) returns just the single sentence.
• It's only when I query with exchars that TextExtracts seems to go beyond the boundary of the lead section, and returns extra characters.

Change 242141 had a related patch set uploaded (by Dbrant):
Prevent TextExtracts from possibly returning wikitext (workaround).

https://gerrit.wikimedia.org/r/242141

Change 242141 merged by jenkins-bot:
Prevent TextExtracts from possibly returning wikitext (workaround).

https://gerrit.wikimedia.org/r/242141

The patch only fixes the app. The problem is still present in TextExtracts.

One friendly vote for bumping priority up a bit on this one :)

Screenshot of a test page I was playing with which exhibits the extract bug:

Seconded. This still happens pretty frequently in our link previews for articles whose lead section is sufficiently small.

Should we just add the exintro=true parameter to the RESTBase /page/summary endpoint and to the apps (maybe web, too)?
Or could we make exintro=true the default? I guess changing the default behavior after the fact could be problematic.

Thanks to @Mholloway for finding this. Adding the Services team since the /page/summary endpoint is implemented directly in RESTBase.

Here's the example query:

• without exintro
• with exintro

Should we just add the exintro=true parameter to the RESTBase /page/summary endpoint and to the apps (maybe web, too)?

Seems like a good idea. I can easily make a PR for RESTBase. Do we want to force-regenerate all summaries to get rid of this or it's fine to rely on natural regenerations happening as the pages get edited?

This is now impacting web too :) See https://phabricator.wikimedia.org/T158221#3100572

The only cases I'm seeing are ones where "==" shows up. Wouldn't it be better to simply do a substr match, excluding any text after and including the first indexOf "==" ?

Are there other types of wikitext that show up?

Oh wait, ignore that's what exintro does...
So there's no bug in TextExtracts here is there? It's just how it's being used? Should we remove the project?

We've fixed it in RESTBase by https://github.com/wikimedia/restbase/pull/771 (not deployed yet).

Since it's affecting hovercards now, we can bump the summary version to ignore all the content stored in Cassandra and regenerate the content on demand instead of waiting for each of the affected articles to get edited. @Jdlrobson is the active regeneration needed on your side?

That doesn't purge the Varnish cached content though, so it will stick for some time until it fells out of the cache.

Spoke with @Pchelolo yesterday and he said that the fix can be SWATed today and the existing cache purged.

@Jdlrobson Will deploy the fix later today, yes. But we can't mass-purge Varnish, so will have to wait a bit until wrong content falls out of Varnish.

Fix confirmed! :)

Contrast with "before" screenshot: https://phabricator.wikimedia.org/T101153#3099947

Nice work!