Add a transaction inbox for outbound chain transactions
Maintainers usually reply within 2 days
@sbackend123 is already working on this.
Since Oct 14, 2026.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go
- Domain
- backend, distributed-systems
Research direction
Start by reading the transaction sending and monitoring flow described in the issue, especially where node state is updated after broadcast. Trace the user API and worker entry points that handle transaction submission and receipts. Done means persisted transactions can be processed asynchronously, retried without duplicate payment, and queried for status; the issue gives no file names or tests to start from.
Written by the indexing model from the issue text.
Description
Task
While a transaction is being sent, the following scenario is possible:
- The connection drops on either side for any reason.
- The transaction may still have reached the mempool.
- The transaction is executed on the blockchain.
- We never learn about it: the transaction is written to the node state only after a successful broadcast to the network, so monitoring does not see it.
- The user sends the same transaction again and pays twice.
The problem becomes sharper once retrying transactions are introduced.
User APIs currently wait synchronously for a receipt or an error. A retrying transaction can take minutes in the worst case.
Proposal
Introduce a transaction inbox pattern for sending transactions on the node.
Before sending a transaction to the blockchain, persist it in the node state and return a unique idempotent identifier to the user.
A separate worker processes these transactions and advances them to sending. Once a transaction has been broadcast to the network at least once, it is marked as sent (its nonce is known) and then follows the existing flow.
An additional API endpoint can also let the user query the transaction status: sent, sending, or a receipt or an error.
Acceptance criteria
AI Disclosure
- This issue contains suggestions and text generated by an LLM.
- I have reviewed the AI generated content thoroughly.
- I possess the technical expertise to responsibly review the AI generated content mentioned in this issue.
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 390
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 23
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ethersphere/bee
-
Chequebook deployment uses a fixed 175,000 gas limit; it needs about 630,000 under Glamsterdam (live on Sepolia since 2026-10-06)Possibly taken @sbackend123 claimed this 8 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ethersphere/bee#5650 · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
ethersphere/bee#5659 ·
Maintainers usually reply within 2 days
-
accepted seen
Difficulty 4/5 3-5 days Newbie friendliness 40/100
ethersphere/bee#5648 · 1 comment ·
Maintainers usually reply within 2 days
-
pusher: chunksWorker deadlocks on a deferred chunk that fails IdentityAddress (send on nil op.Err), halting all push-syncPossibly taken @sbackend123 claimed this 10 days ago. Openseen
Difficulty 3/5 1-2 days Newbie friendliness 75/100
ethersphere/bee#5641 · 1 assignee ·
Maintainers usually reply within 2 days
-
GET /bzz/<ref>/ can 404 off-node, and the 404 is indistinguishable from a missing index documentOpenseen
Difficulty 3/5 1-2 days Newbie friendliness 52/100
ethersphere/bee#5625 · 1 comment ·
Maintainers usually reply within 2 days
Similar issues
-
oss/0 pending team/container-integrations
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
DataDog/datadog-agent#58323 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 Half a day Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
kind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
kubernetes-sigs/external-dns#6816 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
ANSI translator ignores SGR 22/24 (and other attribute-off codes): bold and underline never turn offOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100