Skip to content

Consolidate TransactionPipeline's internal retry loop onto utils/retry.ts #84

Description

@bbjiggy

Description

Follow-up from the #79 spike (see docs/spikes/issue-79-retry-session-multisig.md).

TransactionPipeline (src/tx-pipeline/pipeline.ts) implements its own local withRetry helper
(exponential backoff, per-stage error wrapping). src/utils/retry.ts exports a generic retry()
helper with a very similar exponential-backoff shape, but a different signature (fixed
attempts/delay vs. a policy object, no per-attempt callback, no stage-aware error wrapping). The
two aren't unified, so there are two backoff implementations to maintain.

Proposal

Refactor withRetry in tx-pipeline/pipeline.ts to build on top of retry() from
src/utils/retry.ts (e.g. by extending retry() to accept a delay-strategy function and an
optional per-attempt callback, or by having withRetry call retry() internally), removing the
duplicated backoff loop while preserving TransactionPipeline's existing stage-aware
TrustFlowError wrapping and RetryPolicy (min/max delay) semantics.

This is a refactor of tested, shipped code (tests/tx-pipeline.test.ts, tests/retry.test.ts),
not a new feature — scope it as its own reviewable change rather than bundling it with other work.

Acceptance Criteria

  • Single shared backoff implementation used by both utils/retry.ts consumers and TransactionPipeline
  • TransactionPipeline's existing public behavior (retry counts, delay caps, error codes) unchanged
  • Existing tx-pipeline and retry test suites continue to pass without behavioral changes

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave program

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions