fix(cheatcodes): ensure file sync on vm.writeFile

[grandizzy]

Motivation

• some tests are writing files using writeFile cheatcode and then reading with readFile cheatcode and assert content
• encountered race condition on one project where readFile issued after several writes in the same file failed with

├─ [0] VM::keyExists("<JSON file>", ".addresses.accessManager") [staticcall]
    │   └─ ← [Revert] vm.keyExists: failed parsing JSON: EOF while parsing a value at line 1 column 0
    └─ ← [Revert] vm.keyExists: failed parsing JSON: EOF while parsing a value at line 1 column 0

even if traces were showing write just above the read

• issue cannot be reproduced at will but only if running forge test of the specific test in a loop
• <JSON file> in traces above masked at
  

  foundry/crates/evm/traces/src/decoder/mod.rs

  Line 565 in f60a1d8

  "<JSON file>"

Solution

• introduce write_sync to write_all and sync_all on cheatcode writes

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[0xrusowsky]

i think this makes sense

[zerosnacks]

Makes sense to me, small nit

[onbjerg]

is it important that we flush all data (incl metadata) to disk for this to work? or can we just do File::sync_data?

[grandizzy]

is it important that we flush all data (incl metadata) to disk for this to work? or can we just do File::sync_data?

good point, yeah, I guess we can omit metadata

[DaniPopes]

this makes sense however i wonder if we should lock the file instead of syncing during cheatcode execution? this is on stable now so you can just call file.lock() for write, .lock_shared() for read, and .unlock() and should avoid fs

[grandizzy]

this makes sense however i wonder if we should lock the file instead of syncing during cheatcode execution? this is on stable now so you can just call file.lock() for write, .lock_shared() for read, and .unlock() and should avoid fs

warning: current MSRV (Minimum Supported Rust Version) is `1.88.0` but this item is stable since `1.89.0`
   --> crates/cheatcodes/src/fs.rs:154:14
    |
154 |         file.lock_shared()?;

should I bump?

[DaniPopes]

yes

[grandizzy]

yes

done, please recheck. CI failure due to new node not supporting wss, will ask to open. thanks

[DaniPopes]

should we move to common::fs module?

[grandizzy]

yep, will do, also noticed that writeJson is doing let data_string = fs::read_to_string(&data_path)?; for read which should be locked