Client wikis that have useLegacyChangesSubscription=false can be serviced using wb_changes_subscription, while other client wikis need to be serviced the old way, using wb_items_per_site. It's probably best to use a union of the info from both tables, until we are confident that we can rely on wb_changes_subscription alone.
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | daniel | T66590 Usage Tracking: change dispatcher should use the wb_changes_subscription table | ||
| Invalid | None | T88419 Feature switch for using subscription mechanism for change propagation. | ||
| Resolved | daniel | T90755 Implement hybrid mode for change dispatcher, which uses both wb_items_per_site and wb_changes_subscription. | ||
| Resolved | daniel | T70380 Factor dispatch logic out of maintenance script | ||
| · · · |
Change 202386 had a related patch set uploaded (by Daniel Kinzler):
Hook up subscription lookup based on settings.
Change 202372 had a related patch set uploaded (by Daniel Kinzler):
Introduce SqlSubscriptionLookup