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.
Two more things the swap's design has to cover.
Core's rule for a repeated request (
sameLifecycleContentininternal/integration/lifecycle.go: the same operation, the same requesting person, the same parameters as JSON values) is written twice more in FedWiki, assameRowRequest(internal/integrations/fedwiki/web/requests.go) andsameCreate(internal/integrations/fedwiki/web/api.go). For every parameter FedWiki writes, the three agree except the swap'sswap_park_site_idandswap_activate_site_id, whichsameRowRequestignores because the console chooses the site to park under the lock.sameCreatehas no such reason. Once the site to park leaves a request's parameters, core's rule answers every repeat and both copies can go. Core reads an address through one function that the recording and the lookup share, so a lookup that also applies the content rule is a small addition there.A swap recorded as one act takes two instance locks. Today it records the activated site's request first and the parked site's second (
swapActiveSiteininternal/integrations/fedwiki/web/site_actions.go), not in instance order. That is safe only because both run under the workspace lock and a site belongs to one workspace. An act that records requests on several instances without that outer lock has to take their locks in ascending instance order.The slot holds FedWiki now keeps for creates and activations in flight key on the lifecycle request, not on the workflow id a swap's two requests share, and a swap takes no hold: it takes its slot inside its record transaction. The slot count no longer reads the swap's park-site parameter, so one reader of the two-request convention is gone.