This was detected as part of {T322407} (the currently in progress wikibase suite release)
The assertions failing are:
- https://github.com/wmde/wikibase-release-pipeline/blob/main/Docker/test/selenium/specs/repo_client/item.js#L125-L143
- https://github.com/wmde/wikibase-release-pipeline/blob/main/Docker/test/selenium/specs/repo_client/extensions/scribunto-item.js#L88-L108
These check for the existence of a recent changes entry after an item has been deleted that was linked to a client page.
The recent changes entry should look something like this..
```
type: 'external',
ns: 0,
title: luaPageTitle,
comment: 'wikibase-comment-remove'
```
While initially found in the suite release this is also confirmed to be an issue on test wikidata, and thus probably also happening on wikidata.org
https://test2.wikipedia.org/wiki/Flooberdoober
https://test.wikidata.org/wiki/Q37288
{F35951826}
As you can see on the removal of the site link, the correct entry makes its way into recent changes, but on deletion, this does not happen, and it should.
For wikibase suite this was initially noticed after [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/731045 | Change-Id: Ia9bf35658445dc6b6b260190cdd881bad224ffb8 ]] as up until this point the running of dispatch changes would still lead to these recent changes entries being created. {{T292604}}
For wikidata.org this will have been a regression since around Oct 2021 https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/731014/
Looking at code, the path that originally ran that would have lead to these changes making their way to clients was `JobQueueChangeNotificationSender::sendNotification`, but seemingly this is no longer run
A/C
[ ] tests related to this bug are upstreamed to wikibase proper
[ ] When an article on the client is deleted and the sitelink is removed from the Item then there is an entry in the client Recent Changes to indicate the removal of the sitelink