Side note: Merging duplicates is annoying, it breaks other relationship.

Appears to have been caused by T235666

In T237709#5650151, @Xaosflux wrote:

Side note: Merging duplicates is annoying, it breaks other relationship.

Not sure what you mean here. Duplicates should not be merged?

In T237709#5650151, @Xaosflux wrote:

it breaks other relationship.

I am not sure what you meant by that.

@Ammarpad @Masumrezarock100 no no they should be according to our current workflow, not a complaint on your part! Just a general complaint about phabricator. For example if a ticket has a parent/child relationship, and is merged - the other ticket (generally the earlier of the duplicates) doesn't inherit that linkage.

In T237709#5650742, @Xaosflux wrote:

@Ammarpad @Masumrezarock100 no no they should be according to our current workflow, not a complaint on your part! Just a general complaint about phabricator. For example if a ticket has a parent/child relationship, and is merged - the other ticket (generally the earlier of the duplicates) doesn't inherit that linkage.

I see that. Thanks for the clarification.

Probably introduced by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/543718. Pinging @Pchelolo.

It seems like getMultiNotice() cannot work reliably for deleted revisions, since deleted revisions for the same title may have different page IDs, or may have page ID 0 for old entries. It should probably be skipped if the two revisions don't belong to the same page, or don't match $this->mNewPage->getArticleID().

In T237709#5654649, @daniel wrote:

since deleted revisions for the same title may have different page IDs, or may have page ID 0 for old entries.

Maybe this is (one of) the cause. I noticed it on page deleted&recreated twice - can't compare deleted revisions (even to revisions belonged to the same creation) but possible to retrieve versions. Page created and deleted today.

This just happened to me when I requested https://es.wiktionary.org/w/index.php?title=Especial:Restaurar&target=Discusi%C3%B3n%3Aelefanta&timestamp=20191115152327&diff=prev.

Change 552108 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] DifferenceEngine: Don't try counting revs between deleted revs with different page IDs

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

Change 552108 merged by jenkins-bot:
[mediawiki/core@master] DifferenceEngine: Don't try counting revs between deleted revs with different page IDs

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

I note that this was intended to have a fix, but I'm still receiving the same error on the English Wikipedia.

[Xevv8wpAAEQAADyMBbYAAAFT] 2019-12-07 18:31:16: Fatal exception of type "InvalidArgumentException"

If I'm reading the roadmap correctly, the fix is due to roll out for enwiki as part of 1.35.0-wmf.10, on December 12th.

Somebody please correct me if I've misunderstood the roadmap.

In T237709#5720393, @Seraphimblade wrote:

I note that this was intended to have a fix, but I'm still receiving the same error on the English Wikipedia.

[Xevv8wpAAEQAADyMBbYAAAFT] 2019-12-07 18:31:16: Fatal exception of type "InvalidArgumentException"

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

In T237709#5721181, @Xaosflux wrote:

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

See "Resolved" on https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle

In T237709#5721181, @Xaosflux wrote:

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

That's true. In theory, there should be an engineering task derived from the bug report once the case has been identified. The engineering task gets closed when the patch is merged, the bug report when the fix is deployed. Unfortunately this is annoying overhead to be handled manually, so we(*) often don't do it.

(*) in this case, I.

In T237709#5720394, @RoySmith wrote:

If I'm reading the roadmap correctly, the fix is due to roll out for enwiki as part of 1.35.0-wmf.10, on December 12th.

Somebody please correct me if I've misunderstood the roadmap.

It would be in wmf.8; the assumption I made in T237709#5680065 that wmf.8 was going to be skipped in favor of wmf.9 seems to not have been accurate. But wmf.8 hasn't made it past group 0 due to various issues (T233856). At this point I don't know whether wmf.8 will wind up being deployed at all or if we'll go straight to wmf.10.

In T237709#5721181, @Xaosflux wrote:

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

I remember complaining about that 10 years ago. ;) That was back in the days when getting a fix deployed took months or years, rather than a week or two.

But from a "work tracking" perspective it does make sense: absent the issue somehow not being completely fixed after all, there's no more work to do specific to this task. The deployment that we're waiting for is a bulk deployment of all the changes since 1.35.0-wmf.5. With the way things are, if we left the task open until the deployment actually happens we'd probably actually wind up with no one remembering to actually close it. If we wanted to only close tasks post-deploy, we'd need some sort of "waiting for deployment" queue that someone (human or bot) would go through to make sure all the tasks actually get closed. Maybe that would be a good model to change to, but if so it should be proposed as its own task.

It would be in wmf.8; the assumption I made in T237709#5680065 that wmf.8 was going to be skipped in favor of wmf.9 seems to not have been accurate. But wmf.8 hasn't made it past group 0 due to various issues (T233856). At this point I don't know whether wmf.8 will wind up being deployed at all or if we'll go straight to wmf.10.

In T237709#5721181, @Xaosflux wrote:

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

I remember complaining about that 10 years ago. ;) That was back in the days when getting a fix deployed took months or years, rather than a week or two.

But from a "work tracking" perspective it does make sense: absent the issue somehow not being completely fixed after all, there's no more work to do specific to this task. The deployment that we're waiting for is a bulk deployment of all the changes since 1.35.0-wmf.5. With the way things are, if we left the task open until the deployment actually happens we'd probably actually wind up with no one remembering to actually close it. If we wanted to only close tasks post-deploy, we'd need some sort of "waiting for deployment" queue that someone (human or bot) would go through to make sure all the tasks actually get closed. Maybe that would be a good model to change to, but if so it should be proposed as its own task.

I'm more used to systems like that, so it seems I may have misinterpreted. Generally, "closed" would mean in those instances that a fix has been released to production, and generally verified to be working there. Before that, the ticket would be in an "Approved", "Passed QA", or "Release Ready" state.