Validate notice inputs before choosing a provider
An invalid synthetic recipient passes provider selection and fails differently for A and B. Another path checks the notification preference only after the stub has already accepted the request.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Validation pipelines · Side-effect boundaries · Error contracts
Estimated field mix
- Integrations60%
- Privacy engineering40%
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
- Chain of ResponsibilityCompare
Choose an ordered, short-circuiting validation structure that guarantees notice preferences are checked before any provider side effect.
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.
Acceptance criteria
- Validate appointment identity, synthetic recipient format, and declared notice preference before any adapter call.
- Define the order and short-circuit behavior of validation stages, returning stable reason codes.
- Compare a Chain of Responsibility with an explicit sequence of validation functions; a skipped preference check must be structurally impossible.
Implementation constraints
- Use only synthetic .invalid addresses; do not contact any external address or interpret this exercise as a compliance certification.
Verification to include
- Accept valid synthetic input and assert each required check runs before one provider call.
- Reject malformed recipient and disabled preference with a provider-call count of zero; verify the documented first error when both fail.
Deliverables
- Ordered preflight validation and no-send regression fixtures
Rollout and recovery
Apply the shared validation path to both local providers together; leave explicit rejection visible to the scheduler.
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.