Spec: clarify retries, reconciliation, feature ID guidance#51
Conversation
|
|
||
| Providers SHOULD enforce that at most one FEATURE_TYPE_L3_BASE Feature exists | ||
| per (connection, channel). Attempts to create a second L3_BASE feature for the | ||
| same (connection, channel) SHOULD be rejected with HTTP 409 (Conflict). |
There was a problem hiding this comment.
Do we allow update on feature ?
There was a problem hiding this comment.
While today there is no explicit UpdateFeature, that is more a result of a lack of need to do so. That said, I can definitely envision a world where certain features could be delivered updates, especially as new feature variants are introduced.
|
|
||
| Providers SHOULD enforce that at most one FEATURE_TYPE_L3_BASE Feature exists | ||
| per (connection, channel). Attempts to create a second L3_BASE feature for the | ||
| same (connection, channel) SHOULD be rejected with HTTP 409 (Conflict). |
There was a problem hiding this comment.
While today there is no explicit UpdateFeature, that is more a result of a lack of need to do so. That said, I can definitely envision a world where certain features could be delivered updates, especially as new feature variants are introduced.
|
|
||
| Feature IDs MUST be treated as opaque identifiers. UUIDv4 is RECOMMENDED. | ||
|
|
||
| Providers SHOULD enforce that at most one FEATURE_TYPE_L3_BASE Feature exists |
There was a problem hiding this comment.
I think each explicit FEATURE type is likely to have it's own set of enumeration limits. This likely evolves into a FeatureScope type/field.
I think any deviation for the enumeration will always be a good candidate for 409 errors.
| request and retry. When retrying, clients SHOULD use an exponential | ||
| backoff strategy with jitter and a bounded retry budget (RECOMMENDED: up | ||
| to 5 attempts and/or up to ~60 seconds total). After exhausting the retry | ||
| budget, callers SHOULD reconcile remote state (Get/List) before |
There was a problem hiding this comment.
What does reconcile the remote state mean? I am guessing the active provider should reverse the flow and report failure to the customer (delete features, delete connection, etc)
| 409: CONFLICT. Returned when a server detects concurrent updates to the | ||
| resource. | ||
|
|
||
| 409: CONFLICT. Providers SHOULD enforce that at most one |
There was a problem hiding this comment.
I wonder how this is going to scale over time as we introduce more features with unique validation. Should this be a 400 and provide detailed validation requirements closer to the FEATURE_TYPE_L3_BASE object?
4 participants
Draft PR for review.\n\nSummary:\n- Document retry guidance for timeouts/5xx (bounded retries, exponential backoff + jitter) and reconciliation/redrive expectations.\n- Add optional throttling guidance for HTTP 429 + Retry-After.\n- Clarify Feature identity guidance (opaque IDs; UUIDv4 recommended).\n- Recommend invariant: at most one FEATURE_TYPE_L3_BASE per (connection, channel); reject duplicates with 409.\n\nFiles changed:\n- connection-coordinator/docs/Protocols.md\n- connection-coordinator/paths/connections.yaml\n- connection-coordinator/paths/features.yaml\n- connection-coordinator/schemas/feature.yaml\n\nContext: These items were explicitly suggested for spec standardization during AzureΓåöGCP integration discussions.