A swap of the active site is stored as two single-site requests held together by naming conventions #184
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#184
Reference in New Issue
Block a user
A swap parks one site and activates another.
core.lifecycle_requestsholds one request per instance, so a swap is twoset_statusrows under one workflow id, each naming the other site in its parameters. Readers rebuild it from conventions: a second swap is refused by workflow-id shape (IsSwapRequestWorkflowID), a dismissal pairs rows by workflow id, the slot count ininternal/integrations/fedwiki/store/queries/sites.sqlskips rows withswap_park_site_id, an unstarted swap deletes its rows in separate statements, and FedWiki answers a repeated swap itself (sameRowRequest) because core would compare the park site the console chose.The published protocol (#171) will carry lifecycle requests and FedWiki moves onto it (#174), so the model must say first whether a request can cover several instances, and if not, what holds the rows together.
Done when:
docs/models/provider-integration.mdstates it, #171 carries it, and no code finds a swap by workflow id or parameter key.#179, #181 and #184 share one gap: an action that writes several rows has no record of its own, so readers rebuild it from prefixes, a borrowed request id, or the shape of a workflow id. They take one convention, decided by whichever is worked first and followed by the others. #184 comes first, because the published protocol (#171) needs its answer. #131 asks the same of subscription changes.
The order changes: #187 sets the convention for an action that writes several rows, because its plan-wide acts need it first. A tier removal, a default change or a reorder will record one act and one row per organization it reaches, each pointing at the act. That design is researched against every action that will follow it: this issue's swap, #179's tier changes, #181's rule-change batches, #131's subscription changes and #171's acts, so each fits it. This issue follows the convention, and still answers before #171 starts whether a lifecycle request can cover several instances.