see bug 63409

this also causes Special:DispatchStats to be skewed and the removed wiki reported as "Stalest"

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...

Heh, I ran into this again this week on beta in a slightly different form, but the same underlying issue i think T208307: Beta: JobQueueGroup.php: Domain 'specieswiki' is not recognized.

@Ladsgroup @Michael @dang With the work that you are currently doing around change dispatching, will we be able to close this one?

It will automatically handles this problem. We can close this. I suggest declining this ticket now.