Page MenuHomePhabricator

Checking whether save is possible before assigning Qids
Open, Needs TriagePublic


When somebody is blocked and they try to create a new item, save is not possible but wb_id_counters table is updated, therefore a Qid is lost permanently. This may be an abuse potential (creating higher database load) for malicious users with no way either to detect or to stop on wiki. Ideally no Qid should be assigned if the save is not possible (also when label/description conflict, invalid entity data, etc).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 11 2019, 2:40 PM
Bugreporter updated the task description. (Show Details)Sep 11 2019, 2:41 PM

A cause for this problem might be, that in the last few days some indexes are updated not immediately, but with a delay of some days.

For example the result of this

Petscan Query should show only articles without wikidata objects.

In the last days, also entries are shown, where the articles already have been connected to a (new or existing) wikidata object.

Bugreporter added a comment.EditedSat, Sep 12, 2:08 PM

It's true that IDs may be "swallowed" by unsuccessful attempts to create an item. But I don't see this as a problem. The IDs have no significance, they could just as well be chosen randomly instead of sequentially. The ID system may well be changed to something else entirely at some point, e.g. GUIDs.

I want to thank you for reporting this anyway, because it *might* have been an indication for Something Bad happening, like items just vanishing without a trace. But I don't see any evidence of that. So, closing WONTFIX.

This is already posted on wiki, but also post here for reference:
Allocating one ID requires one read and write of wb_id_counters table. It is possible that some malicious users doing a large number of failed creation, which may significantly increase the database load. What's worse are 1. There are no ways on wiki to find out users who are doing failed item creation and 2. Blocking the user does not solve the issue as IDs will still be allocated.

Before T213817: Use separate DB connection for (Sql/UpsertSql)IdGenerator in Wikibase is fixed, things are even much worse, as there was a DoS potential: malicious users can produce many database errors (logspam), or even impede others creating new entities.