Spike: Temporal/Step Functions for long-lived streaming schedules and child workflows
## Description
**Spike** whether **durable** workflow engines (**Temporal**, AWS SFW, or org standard) fit
multi-day or monthly stream accrual with Soroban settlement, better than
pure cron+queue. Output is an ADR with build vs not-build recommendation, not
production roll-out in 96h unless trivially adopted.
## Requirements and context
- **Prototype** 2 flows: `sleep-until` next tick, **child** workflow per stream.
-
Cost and operational comparison vs current BullMQ (from existing issues) + cron.
-
Security of worker identity and secrets; network egress controls.
-
ADRs in docs/adr/.
-
If rejected, document risks of staying on cron (missed tick, idempotency).
## Suggested execution
1. `git checkout -b spike/temporal-streams`
-
Timebox 3 days; do not block release train on the spike.
-
PR with ADR, no need for 95% test coverage (spike) but include tests for any code merged.
-
Guidelines on timeframe: 96h to ADR+prototype branch; mark issue done when merged.
-
Child issue for production if approved.
- Run the full test suite; add or update tests until the agreed coverage bar is met.
- Cover edge cases listed in this issue; document any intentional exclusions with brief rationale in the PR.
- Include relevant test output (e.g. test runner summary) or a link to a passing CI run in the pull request.
- Add security notes for auth, keys, PII, chain settlement, or money movement (assumptions verified, out-of-scope items).
Example commit message
docs(adr): spike Temporal (or org equivalent) for long-lived stream and Soroban workflows
Guidelines
- Target: at least 95% coverage on new or meaningfully changed code (per the repo’s standard tooling).
- Documentation: update contributor-facing or API documentation where a reviewer would be blocked without it.
- Timeframe: 96 hours to ready-for-review (surface blockers early).
Spike: Temporal/Step Functions for long-lived streaming schedules and child workflows
multi-day or monthly stream accrual with Soroban settlement, better than
pure cron+queue. Output is an ADR with build vs not-build recommendation, not
production roll-out in 96h unless trivially adopted.
Cost and operational comparison vs current BullMQ (from existing issues) + cron.
Security of worker identity and secrets; network egress controls.
ADRs in
docs/adr/.If rejected, document risks of staying on cron (missed tick, idempotency).
Timebox 3 days; do not block release train on the spike.
PR with ADR, no need for 95% test coverage (spike) but include tests for any code merged.
Guidelines on timeframe: 96h to ADR+prototype branch; mark issue done when merged.
Child issue for production if approved.
Example commit message
docs(adr): spike Temporal (or org equivalent) for long-lived stream and Soroban workflowsGuidelines