daniel added a subscriber: daniel. daniel added a comment. Herald added a subscriber: Aklapper.
I'm unsure how to best solve this. We could: - automatically remove the old wiki from wb_changes_dispatch. Disadvantage: if you add the wiki back, the dispatcher would then send //everything// to it, since it no longer knows where it left off. - we could just ignore this situation and not log it. Disadvantage: Then the removed wiki would still show up in the stats as most lagged. Also, if we have many removed wikis, they could take up all the "top lagged" slots, leading to the dispatcher never finding a wiki it can dispatch to. - we could flag the entry in wb_changes_dispatch as removed. Disadvantage: if you add the wiki back into the config, it would still be ignored until the flag is removed from the database entry. How often does something like this happen? I'm inclined to think that the cure is worse than the disease... we'd introduce magic that would lead to more inconsistencies. Is manually removing a row from the database really so bad? Wikis are usually not decommissioned that often... TASK DETAIL https://phabricator.wikimedia.org/T65411 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, daniel, Wikidata-bugs, aude, Lydia_Pintscher, Malyacko _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
