feat(sdk): reconcile unknown transaction outcomes with a durable submission journal

[karagozemin]

Difficulty

Hard — production engineering across multiple components; a small cleanup or test-only patch does not complete this issue.

Context

The submitter exposes a hash/status response, and the OZ Channels adapter throws when an accepted request has no hash. A lost acknowledgement must be distinguishable from a rejected transaction before callers construct another operation.

Starting points

• packages/sdk/src/submitter.ts
• packages/sdk/src/client.ts
• packages/sdk/src/errors.ts

Scope

• Define prepared, submitted, unknown, confirmed and failed states with a pluggable durable journal.
• Bind operation identity to network, contract, caller, method, arguments and the signed transaction hash.
• Reconcile direct RPC and relayer acceptance/confirmation before permitting a replacement transaction.
• Make retry/cancel policy explicit and provide structured recovery information to callers.

Acceptance criteria

• An accepted request followed by a dropped response enters unknown and is reconciled rather than blindly recreated.
• Concurrent calls sharing a logical operation key cannot create different independently executable submissions.
• A key cannot be reused for another payload, contract or network.
• Journal replay after restart produces the same terminal outcome for both submitter adapters.
• Timeout, not-found, rejected, expired and confirmed responses have deterministic state transitions.
• No secret or signed XDR is logged; any persisted signed material has a documented access/retention policy.

Verification

Use deterministic fake RPC/relayer servers, concurrent clients, acknowledgement loss and process restarts. Assert logical effects rather than claiming that network delivery itself can occur exactly once.

Out of scope

Keeper lease ownership, changes to auction clearing, new relayer vendors or live fund transfers.

[Iker2522]

#357

feat(sdk): reconcile unknown transaction outcomes with a durable submission journal
karagozemin
karagozemin
Sub-Rosa-Issue
Sub-Rosa-Issue / sub-rosa-issue
opened 10/9/2026
0 comments
Postularme a este issue

Submit your motivation and experience. It will be published as a comment on GitHub from your account.

1 application per user
•
Direct GitHub comment
Assigned to
Unassigned
Descripción
Difficulty
Hard — production engineering across multiple components; a small cleanup or test-only patch does not complete this issue.

Context
The submitter exposes a hash/status response, and the OZ Channels adapter throws when an accepted request has no hash. A lost acknowledgement must be distinguishable from a rejected transaction before callers construct another operation.

Starting points
packages/sdk/src/submitter.ts
packages/sdk/src/client.ts
packages/sdk/src/errors.ts
Scope
Define prepared, submitted, unknown, confirmed and failed states with a pluggable durable journal.
Bind operation identity to network, contract, caller, method, arguments and the signed transaction hash.
Reconcile direct RPC and relayer acceptance/confirmation before permitting a replacement transaction.
Make retry/cancel policy explicit and provide structured recovery information to callers.
Acceptance criteria
An accepted request followed by a dropped response enters unknown and is reconciled rather than blindly recreated.
Concurrent calls sharing a logical operation key cannot create different independently executable submissions.
A key cannot be reused for another payload, contract or network.
Journal replay after restart produces the same terminal outcome for both submitter adapters.
Timeout, not-found, rejected, expired and confirmed responses have deterministic state transitions.
No secret or signed XDR is logged; any persisted signed material has a documented access/retention policy.
Verification
Use deterministic fake RPC/relayer servers, concurrent clients, acknowledgement loss and process restarts. Assert logical effects rather than claiming that network delivery itself can occur exactly once.

Out of scope
Keeper lease ownership, changes to auction clearing, new relayer vendors or live fund transfers.

[ZacLou]

I am a senior full-stack developer with 15+ years of experience. I have deep expertise in SDK development, transaction processing, and building robust financial systems. I have implemented durable submission journals, transaction reconciliation, and error handling pipelines in production. Ready to start immediately.

[Joyful12-tech]

Hello Maintainer! I'd like to work on this issue. I can deliver it following the requirements and submit a quality PR within 2 days. Thank you!

[ranjeet150]

Hello @maintainers,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Trace the regression in Sub-Rosa-Issue/sub-rosa-issue causing feat(sdk): reconcile unknown transaction outcomes with a durable submission journal and implement a targeted, minimal fix.
• Testing & Verification: Add a reproduction test case to prevent any future regression.
• Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

Looking forward to contributing—please feel free to assign!

[guptakumarranjeet150]

Hello @maintainers,

I can tackle feat(sdk): reconcile unknown transaction outcomes with a durable submission journal. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Sub-Rosa-Issue/sub-rosa-issue
• Implementation: Trace the regression in Sub-Rosa-Issue/sub-rosa-issue causing feat(sdk): reconcile unknown transaction outcomes with a durable submission journal and implement a targeted, minimal fix.
• Testing: Add a reproduction test case to prevent any future regression.
• PR: Atomic commit with clean git hygiene and passing CI

Excited to work on this—please assign to me and I'll submit a clean PR shortly!