Non-atomic `fs::write` in `rgb_utils` causes node crash and data corruption

[free-free-6]

Summary

write_rgb_channel_info in rgb_utils/mod.rs uses fs::write() to update RGB channel info files. fs::write internally performs two separate syscalls:

1. open(O_TRUNC) — truncates the file to 0 bytes
2. write(data) — writes new content

This causes two problems:

Problem 1 — Runtime crash (race condition): If another thread reads the file between syscall 1 and 2, it reads an empty file, serde_json fails with EOF, and the thread panics. The panic poisons the shared Mutex, cascading to all other threads and crashing the node.

Problem 2 — Persistent data corruption: If the process is killed (SIGKILL / OOM / docker stop / power loss) between syscall 1 and 2, the file is permanently left as 0 bytes. On restart, any code path that reads this file panics, making the node unable to start.

Affected code

rust-lightning/lightning/src/rgb_utils/mod.rs:

• write_rgb_channel_info
• write_rgb_payment_info_file
• fs::write calls in color_commitment

All write to files in .ldk/ directory without any synchronization or atomic write pattern.

How to reproduce

channel_info_file_race.txt
Attached test file: channel_info_file_race.txt (rename to .rs, place in src/test/)

The test opens an RGB channel, then fires rapid concurrent payments while 5 background tasks continuously call /listchannels. The payments trigger write_rgb_channel_info (via PaymentSent events), while /listchannels calls parse_rgb_channel_info on the same file. Within ~20-30 rounds the race condition is hit:

parse_rgb_channel_info thread_id: ThreadId(3)   ← reading
write_rgb_channel_info thread_id: ThreadId(5)   ← writing (487µs)

panicked at rgb_utils/mod.rs:586:
valid rgb info file: Error("EOF while parsing a value", line: 1, column: 0)

panicked at channelmanager.rs:13758: PoisonError { .. }
panicked at channelmanager.rs:4260:  PoisonError { .. }
...cascade...

Register the test in src/test/mod.rs:

mod channel_info_file_race;

Run:

cargo test channel_info_file_race -- --test-threads=1 --nocapture

Note: the test uses worker_threads = 4 internally to enable true thread concurrency.

[lukegao209]

The issue described here is only one specific scenario involving how channel information is written. However, the core problem is broader: it is really about the overall RLN system design for managing channel-related state.

For example:
• whether a database should be used instead of relying mainly on files,
• whether there should be a caching layer, since channel information is currently read from files and this results in significant I/O overhead,
• and how atomicity should be handled for file read/write operations and related state updates.

So in my view, this is not just an isolated issue about writing channel information, but a more fundamental question about the architecture and state management approach of the entire RLN system.

[zoedberg]

Thanks for reporting this.

PRs RGB-Tools/rust-lightning#17 and #95 are about to substitute the file-based storage with a database one. In those PR we are also discussing how to guarantee atomicity of read/write operations.

In the meantime it would be great if you could open a PR with the test you attached here.

[zoedberg]

@free-free-6 would you please open a PR with the test you attached here? I would like for PR #95 to be rebased on top of your test, to prove the test passes after the changes there

[free-free-6]

How to reproduce

@zoedberg here