Reliability: RocksDB request updates are read-modify-write without transactions

[ch4r10t33r]

Summary

Storage::update_request_status, update_request_tx_hash, and related paths load a request, mutate it in memory, and write it back (src/storage.rs). There is no optimistic locking or RocksDB transaction.

Risk

Concurrent tasks (for example JSON-RPC handler vs. background receipt poller vs. gas-bump loop) can interleave such that one writer overwrites another’s fields (lost status transition, dropped transaction_hash, or inconsistent task_id index vs. row). Under load or slow RPC this becomes more likely.

Suggested mitigations

• Use a single-writer queue per request id, or RocksDB transactions / merge operator.
• At minimum, compare-and-swap on a monotonic version field stored with each request.

References

• src/storage.rs (update_request_status, store_request)