Remove the transparent send proxy that retries an ambiguous timeout
A transparent Proxy automatically repeats any timed-out call. The local stub can accept a notice and drop the response, so the hidden retry records two accepted deliveries while the application sees one success.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Idempotency · Failure semantics · Abstraction review
Estimated field mix
- Integrations50%
- Distributed systems50%
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
- ProxyRemove
Remove transparent retry behavior that changes send semantics after ambiguous completion, exposing retry decisions and operation identity to the application.
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
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PPROVIDER-101 · Normalize the second provider's acknowledgement without inventing delivery
- PPROVIDER-102 · Keep provider SDK types out of appointment rules
- PPROVIDER-103 · Validate notice inputs before choosing a provider
- PPROVIDER-104 · Decouple notice format from the selected transport
- PPROVIDER-105 · Record one bounded telemetry event around each provider attempt
- PPROVIDER-106 · Replace the scheduler's six-call notification sequence with one bounded operation
Acceptance criteria
- Remove hidden retry behavior from the send proxy and expose ambiguous completion as unknown.
- If a retry is explicitly requested, preserve the original operation identity and require a declared provider deduplication contract; otherwise refuse the retry.
- Record attempt identities separately from operation identity so the handoff can explain what was tried without claiming recipient delivery.
Implementation constraints
- Keep the exercise local and deterministic; a timeout does not prove a provider rejected the operation, and selecting the other provider is not a safe default.
Verification to include
- Have the stub accept then lose its response; assert one attempt and an unknown outcome with hidden retries disabled.
- Try an explicit retry against a stub lacking deduplication support and confirm it is refused; test convergence on a deduplicating stub.
Deliverables
- Proxy simplification, explicit retry contract, and ambiguous-timeout reproduction
Rollout and recovery
Disable automatic retry in the local composition first; review stored unknown operations before any explicit retry experiment.
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.