fix: always write root index in v4 format

[pmleveque]

Problem

After f5c7b9c, all write operations (mkdir, put, mv) fail with:

400 {"message":"invalid hash"}

on the root docSchema PUT.

Root cause

f5c7b9c correctly reads the server's current schema version in Mirror(), but then propagates that version into IndexReader() and Rehash() for writes. For accounts whose root index was still v3 format, this causes rmapi to write a v3-format root blob — which the server rejects.

In testing, the server still accepted existing v3 per-document docSchemas, but rejected new v3-format root docSchema writes. New root writes appear to require v4 format.

Fix

IndexReader() always produces v4 output. Rehash() is simplified to always SHA-256 the IndexReader() content. SchemaVersion on HashTree is still populated by Mirror() for informational logging but no longer drives write behaviour.

The root self-migrates: after the first successful v4 write, the server's root becomes v4 permanently and future Mirror() calls detect v4 going forward.

RMAPI_FORCE_SCHEMA_VERSION still overrides the serialized schema version for debugging. Note that Rehash() always uses SHA-256 regardless, so forcing v3 is only useful for inspecting failure modes — it does not restore the old v3 write path.

Testing

Added TestRootIndexWritesV4WhenMirroredV3: creates a HashTree with SchemaVersion: SchemaVersionV3 (as mirrored from an old server root), calls IndexReader(), and asserts the output is v4. Also asserts Rehash() produces sha256(IndexReader bytes).

Verified mkdir and put succeed on a live account that previously had a v3 root (was broken after f5c7b9c).

[pmleveque]

Additional verification on the root cause: I tested both sides of the earlier hypothesis.

For a v3 root body, HashEntries(parseIndex(body)) matched the URL hash — so the v3 hash algorithm was correct. But the server still rejected the root PUT with 400 {"message":"invalid hash"}. After serializing the root as v4 and hashing the v4 body with SHA-256, the same account successfully completed mkdir and put.

The failure is not a hash mismatch in the v3 sense — it's that the server no longer accepts v3-format bodies for new root docSchema writes at all.

[JeeWeetje]

Independent reproducer — same symptom, different account.

Context

I have a Cloude Cowork daily skill that rolls over my last todo (usually yesterday's) to today and only rolls over itms not checked off. The older copy gets back upped in 1.Done folder.

What I did

Hit this on April 26–27 2026 across multiple attempts. All put calls failed with 400 {"message":"invalid hash"} on the root docSchema PUT. Notably, mv between existing folders (e.g. rmapi mv "/To Do" "/1. Done/To Do 2026-04-24") worked — only put was blocked. Read ops (ls, get, geta, refresh, account) all normal. That mv-vs-put asymmetry might narrow down which write paths actually go through the v3 root-rewrite codepath.

Things that did not help, in case it saves anyone time:

• Clearing ~/Library/Caches/rmapi/tree.cache
• rmapi refresh immediately before put (no other ops between)
• Re-authenticating from scratch (rm rmapi.conf, fresh device pairing, fresh JWT)
• Rebuilding from master HEAD
• --force, --coverpage=1, --content-only
• Different upload paths (/, /8. Temp/), different filenames, varied content (1 KB hello-world PDF, the original .pdf extracted from a working in-cloud notebook, full .rmdoc bundle)

Trace excerpt with RMAPI_TRACE=1:

PUT /sync/v3/files/<sha256>
rm-filename: root.docSchema
content-type: text/plain; charset=UTF-8
x-goog-hash: crc32c=...
→ HTTP 400 {"message":"invalid hash"}

Account: SyncVersion: 1.5, root presumably v3 (account created earlier this month, never explicitly migrated). Will build the fix branch and report back.

[JeeWeetje]

Confirmed — fix branch resolves it.

Built pmleveque:fix/root-schema-v4-write-regression and re-ran the same put that was 400-ing minutes earlier on master:

$ rmapi put hello.pdf /8. Temp/
uploading: [hello.pdf]...OK

Followed by a real-world mv + put round-trip on the same account that was previously broken — both succeeded, root self-migrated to v4 as predicted. Ran another put afterwards: still works, so the migration is sticky.

LGTM. Thanks for the fast diagnosis and clean fix.

[charlieellington]

Hitting this exact bug today on v0.0.32 / macOS. ls works fine, but every put / mkdir / mv fails on the root docSchema PUT with:

PUT /sync/v3/files/<hash> HTTP/1.1
→ HTTP/2.0 400 Bad Request
{"message":"invalid hash"}

Confirms the v3-format root index is no longer accepted server-side, matching your root-cause analysis. Thanks for the patch — would be great to see this merged so a v0.0.33 can ship.

[rmitchellscott]

@ddvk can you take a look at this one and cut a release if good to go?