"Let's rewrite it" has become a bit of a battle cry, good point :-) Agreed that we would schedule along with other cleanup work, later or never, so for now let's just decide whether it's a bug and what can be improved.

Interesting! The first error makes sense, I'd say. The second I agree is misleading, let's rewrite it.

This happened. FWIW, the form is only reachable when a debugging flag is configured on the server, so it's not a user-facing feature.

This happened, and the feature is deployed.

The "unbreak now" issue is fixed in production, but during code review we found that the fix needs to be rolled back and reimplemented. As currently deployed, the code will show inline errors for any refs with name="" or a name with pure whitespace. Although this is a degenerate case, it wasn't erroring in the past, and our guideline for the rewrite has been to not introduce any new errors for existing wikitext.

More examples of fixing the error (thanks, @Reedy!):
https://zh.wikipedia.org/w/index.php?title=User%3AAtana_goodwin%2FWork14&type=revision&diff=57736642&oldid=49425248

I've already hit the wall with my editing approach. https://zh.wikipedia.org/w/index.php?title=User:Atana_goodwin/Work14&oldid=49425248 cannot be edited because it's under the user namespace, but seems to be breaking the RefreshLinksJob.

Hopefully the second patch addresses the remaining exceptions. There was an interesting edge case where name="" in a template-generated reflist causes a crash. The patch does additional validation to catch these.

In T151308#5808336, @thiemowmde wrote:

Another option might be to use the already available ….attrs.extends value to access the parent, and display it's contents while editing the sub-reference.

I would still like this reset. I've posted a user committed identity hash in https://www.mediawiki.org/w/index.php?title=User:Adamw&diff=3485365&oldid=3299259&diffmode=source

Um, just noticing that the error I'm chasing is different than the one reported in this task.

LogicException from line 309 of /srv/mediawiki/php-1.35.0-wmf.14/extensions/Cite/src/ReferenceStack.php: Cannot roll back ref with unknown group "".

I've "fixed" the article to mitigate the logspam: https://fr.wikipedia.org/w/index.php?title=Nachi_(navire)&diff=166346502&oldid=159845204

It's caused by nested References templates,

How exciting! This is a page which causes a render exception every time it's viewed: https://fr.wikipedia.org/wiki/Nachi_(navire)

My mistake, what I meant to show was this case:

<ref name="a">First</ref>
<ref name="b">Second</ref>
<ref extends="a" name="b">Second</ref>

In T222783#5221331, @thiemowmde wrote:

A good help page to link to is https://commons.wikimedia.org/wiki/Commons:File_types.

In T242110#5789469, @WMDE-Fisch wrote:

Should we consider the task done now with the patch merged? Or what about the comment on the last patch? Should this go into an extra ticket?

I closed this too quickly. Behavior is indeed different if <references> is used instead, which is incorrect. The snippet given in the task description should be allowed, and implementation will require changes to the ReferenceStack "undo" logic.

The error is actually with the parent ref. It must be used outside of the <references> section:

Just a note during sprint planning: I think we can omit this feature from the MVP, by agreeing to always error if a ref is written using "extends" in some reuses but not others.

Summarized in the task description, now I think we can close and continue work by reviewing the dashboards in the next ticket.

I changed the title and description because this seems to be about reused refs, the "with the same content" part is irrelevant.

I noticed that the criteria listed in the "why?" of this task could also be satisfied by simply expanding the wikitext without fully rendering. For example:

Let's demo and close.

Oops, I see the same discussion already took place on the deduplicated task.

Here's the syntax which matches the current feature, and it already does work correctly for subreferences. I think we should close this task.

this is how top-level references also behave

This patch is currently a bottleneck to the others: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Cite/+/559671/

Assigning random story points, please revise as needed.

Assigning random story points, please revise as needed.

Assigning random story points, please revise as needed.

Adding a random story point estimate. The incident report looks complete, I'll tick that box.

There might not be a way to measure the impact of this change. We aren't measuring the total memory extent of each thread, and garbage collection is (allegedly) disabled, with no recorded metrics that might show us decreased memory pressure.

I ran out of steam on this iteration, here's a summary of what has changed:

• All usage instructions moved from Extension:Cite to Help:Cite.
• Configuration variables documented.
• Extension template metadata updated.
• Clean up formatting, translate tags, and details.
• Deprioritize "follow" feature by moving lower in the doc.
• Remove error message documentation.

As can be seen in patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530148/ , if we hook in after the external 3-way merge tool, we can detect whether automatic resolution failed.

We also have access to the new, unsaved revision text.