Settle unconfirmed note PATCHes with a read-back

Merged
JS
16h ago
+314-89

A note PATCH that ends in a 5xx, a timeout, or a dropped connection was reported as WriteUnconfirmed at once, leaving the agent to call hackmd_get_note and compare. confirm_note_write now takes the PATCH outcome and runs the same read-back a successful PATCH gets: a read showing the note as sent makes the call succeed, anything else (a failed read included) keeps the original WriteUnconfirmed, and the PATCH is never resent. This supersedes #24, rebased onto the snapshot work in #27 so the settled read also seeds the snapshot cache, with one fix: that read must prove the write, so a blank title and the folder, which a successful update leaves unchecked, are compared too. Without that, a read of the unchanged note confirmed a failed folder move or blank-title update.

Verified with make check (388 lib tests plus integration targets) and cargo clippy --all-targets --all-features -- -D warnings, both clean. Each new contract was mutation-checked by breaking it and watching its test fail, except "a 422 PATCH is never read back", which the fixture cannot observe; that test only pins the error passing through. Left out: create's folder-fallback PATCH still bypasses this path, and the read-back after a failed PATCH still polls the full window rather than reading once.

Closes #23


Summary by cubic

Settles unconfirmed note PATCHes (5xx, timeout, dropped connection) with a read-back, so the agent no longer has to call hackmd_get_note and compare after an uncertain write.

  • A read showing the note as sent makes the call succeed; anything else (a failed read included) keeps the original WriteUnconfirmed, and the PATCH is never resent.
  • The settling read must prove the write: a blank title and the folder, otherwise left unchecked, are compared too, so a read of the unchanged note does not confirm a failed folder move or blank-title update.
  • Folder placement is proven only by an empty list (root) or a single matching folder, since the ancestor list's order is unverified.

Closes #23.