Normalize the second provider's acknowledgement without inventing delivery
Provider A returns accepted plus a request ID; provider B returns queued with a nested reference. The existing mapper calls both delivered, even though neither acknowledgement confirms a recipient received the notice.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Adapter contracts · Response validation · Error modeling
Estimated field mix
- Integrations70%
- API design30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- AdapterApply
Translate incompatible acknowledgement payloads into a shared contract without overstating queued or accepted messages as delivered.
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 maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied.
Setup prerequisites
- HTTP contracts
- Asynchronous cancellation
- Dependency injection
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Define a shared result contract for accepted, rejected, and unknown outcomes with provider identity and an optional provider reference.
- Map both declared acknowledgement shapes to accepted while preserving their references; never map acknowledgement alone to delivered.
- Malformed success payloads and unknown response codes return a typed integration error without exposing raw recipient data.
Implementation constraints
- Use an Adapter for each local stub; preserve unsupported semantics explicitly rather than forcing every response into a success boolean.
Verification to include
- Map representative A and B acknowledgements and compare the shared contract.
- Return a success status with a missing required reference and an undocumented state; assert explicit failure.
Deliverables
- Provider adapters, shared result contract, and mapping fixtures
Rollout and recovery
Run both adapters against local scripted responses before selecting B for synthetic requests; retain A's mapping for regression comparison.
Value of the work
For the engineer: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults.
For the team: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion.
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.