grenadeandClaude Opus 5.5
1c9467c38d
ci / gate (push) Canceled after 3m50s
The intents account (#71) lives on NEAR, where a node knows nothing of shards it does not track. NearRpc is the port: every call names the account it is about. HttpNearRpc works out that account's shard from the layout and asks our node for it (s<shard>.near.blackbeard.observer), then the public RPCs. The endpoints are in near.toml, which an operator file in the data directory replaces. Our nodes are trusted only while synced. A fresh node answers from the height it has reached, so the shard-13 node still syncing today said wrap.near does not exist. The adapter therefore checks each of our names' /status at most once a minute and skips one that is syncing or more than two minutes behind. A node that disowns its shard drops the cached layout, which is how a reshard shows up. Nothing waits for a transaction's outcome, which no single shard node can assemble; send returns at INCLUDED_FINAL. Two of #72's notes were wrong and are corrected here: - view_access_key wants the full key (ml-dsa-65:<base58>); the ml-dsa-65-hash: handle that key listings show is refused as a parse error. - A missing key comes back as a result carrying `error`, not as an RPC error. It is read as UNKNOWN_ACCESS_KEY. Live tests (ignored by default) read accounts on shards 4, 7, 8 and 13, find #72's ML-DSA key and not its deleted ed25519 one, and make a view call. Shard 13 fell through to the public RPC past the syncing node. The app wires it in with #74, the first thing that reads it. Closes #73 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NUx7SPonBnB3ofU4mH41WT