+1
−0
+31
−0
Loading
Three gaps left by zone sync. A partner was told about zone changes only
when an agreement was written, so an agreement reaching valid_until kept
its zones on the partner's side until the partner read
GetFederationDetails, and a callback the partner didn't take was never
sent again. A withdrawn zone left both sides' subscription records behind.
And the partner's platformCaps lived only on the zones it offered, so zones
it added after withdrawing all of them carried none.
As the provider, FM now records on the inbound federation the zones the
partner was last told it has (offered_zone_ids, set by the CreateFederation
answer, GetFederationDetails and every delivered callback) and sends the
difference against what the agreement offers now. Outside valid_from and
valid_until an agreement offers nothing. The check runs on every agreement
write, at the next agreement boundary, and every FM_ZONE_OFFER_SWEEP_SECONDS
(default 600), which also resends what didn't arrive. A Postgres advisory
lock per partner keeps replicas from sending the same change. A zone that
leaves the offer drops the partner's subscription to it.
As the consumer, a zone the partner stops offering (ZONES REMOVE or a
GetFederationDetails without it) drops our accepted-zone record, and the
partner's platformCaps are kept on partner_ops.supported_apis.
Migration 0009 adds both columns and fills supported_apis from the zones
already held. Federations from before it get offered_zone_ids on FM's
first check, taken as what the partner holds.
Co-Authored-By:
Claude Opus 5.5 <noreply@anthropic.com>