We may need some help from Wikidata folks on the question of how we discover such things. Any API? Or any way to patch it so that they would appear in the stream? After all, there's nothing informative in the Q-ids themselves, so I do not see how any harm could follow from having them in the public stream, even if the content of the item has to be suppressed.

That is not specific to Wikidata. IMHO it is not a good use of time to create a software solution that is specific to Wikidata. Any Mediawiki installation that uses page deletion with suppression has the same problem for anything that mirrors it via changes. So this task in its generic form has nothing to do with Wikibase.

What do the rest base people do to not leak stuff like this?

The easiest solution that is specific for Wikidata is: Tell the few people with this capability to not use it, but instead oversight revisions (possibly create a new one first). Maybe it can even be disabled via configuration?

In T105427#1446860, @JanZerebecki wrote:

The easiest solution that is specific for Wikidata is: Tell the few people with this capability to not use it, but instead oversight revisions (possibly create a new one first). Maybe it can even be disabled via configuration?

And what happens when a steward does an emergency suppression and isn't familiar with this technical restriction?

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS telling it to force update the page.

In T105427#1448872, @Legoktm wrote:

And what happens when a steward does an emergency suppression and isn't familiar with this technical restriction?

If you don't read https://www.wikidata.org/wiki/Wikidata:Oversight before doing that it is natural that you are going to make errors. Anyway the error can be corrected afterwards. How often does an emergency suppression of an entity with only one revision happen?

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS telling it to force update the page.

Then what about all the WDQS instances not hosted at the foundation and the mirrors and so on?

Is some public log of suppressed page and revision ids more work than your proposed solution? (Preferably it would be in RecentChanges.)

I think we should write a small WDQS extension that hooks into ArticleDeleteComplete, and sends a HTTP request (maybe with an auth token?) to WDQS

The problem here is that WDQS is purely pull now. Adding push to it adds a lot of complication, as Wikidata now needs to know about every instance of WDQS is running, and be able to notify them, which requires a whole host of functionality developed on both sides. I'm not sure developing this just for this narrow case is warranted.

Alternatively, could we have some API that just would show the list of Q/P-ids that were suppress-deleted? Maybe some extension to query API or separate API? The Q/P-id does not have any private/sensitive information in it, and as far as I can see, can not contain any info covered by oversight policy. So the impact of the API saying "this ID was deleted, no further info available" would be minimal.

Of course, even better solution would be to just have it in the RC stream, which also doesn't have any info besides IDs anyway, as I understand.

Change 226931 had a related patch set uploaded (by Smalyshev):
T105427: produce a blank RC entry on suppressed deletes

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

Change 227372 had a related patch set uploaded (by Smalyshev):
T105427: create nearly-blank RC entry for suppressed events

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

Proposed note to be added on https://www.wikidata.org/wiki/Wikidata:Oversight

https://www.wikidata.org/wiki/User:Smalyshev_(WMF)/Oversight_note

Excellent work, Stas. I did some trivial reformatting of the note.

At this stage, I'm just going to post the note directly onto the Oversight page with an explanatory note on the talk page. If someone on Wikidata objects, they can revert me and we can discuss.

Change 226931 abandoned by Smalyshev:
T105427: produce a blank RC entry on suppressed deletes

Reason:
Probably not the right way to solve it, we'd get to that with Event Bus

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

Change 227372 abandoned by Smalyshev:
T105427: create nearly-blank RC entry for suppressed events

Reason:
Probably not the right way to solve it, we'd get to that with Event Bus

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

This will be resolved by the new Streaming Updater. This ticket will be closed.