Refresh expired connector credentials once per account
Ten jobs receive token-expired at once, all refresh, and a rotated token is overwritten by an older response. Serialize refresh by connector identity and persist credential revisions safely.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Credential lifecycle · Concurrency · Secret handling · Provider integration
Estimated field mix
- Integrations40%
- Security30%
- Distributed systems30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional consultancy books appointments across time zones. The first connector duplicates events after timeouts and offers slots during stale calendar sync. Use a local calendar-provider double and synthetic calendars.
Setup prerequisites
- Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens.
- Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CAL-101 · Reject local times that do not identify one instant
- CAL-102 · Merge overlapping busy intervals before offering slots
- CAL-103 · Label unavailable or stale free/busy data instead of showing open slots
- CAL-104 · Reserve a slot atomically when two customers choose it
- CAL-105 · Reconcile a create-event timeout before trying again
Acceptance criteria
- Concurrent expiry responses share one refresh operation per connector account.
- Credential writes use version checks so an older refresh cannot overwrite a newer rotation.
- A revoked grant stops new provider mutations, records reconnect-required, and never logs credential values.
Implementation constraints
- Use synthetic opaque tokens and a local token endpoint double.
- Store credentials through a secret-store interface; do not hard-code a production key.
Verification to include
- Expire a token under ten concurrent calls and assert one refresh with successful versioned reuse.
- Return refresh responses out of order and a revoked grant; verify no stale overwrite and no further mutations.
Deliverables
- Credential lifecycle port and refresh-race tests
Rollout and recovery
Canary the new refresh path on a synthetic connector; force reconnect when credential authority is ambiguous.
Value of the work
For the engineer: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries.
For the team: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.