share / sharedb / 40933941591

98%

master: 97%

push

github

✨ Add `retry` middleware action (#761)

* ✨ Add `retry` middleware action

When a commit loses the race to another op, `SubmitRequest.retry()`
re-runs `submit()` on the same request. That re-fetches the snapshot and
resets fixups, but keeps any properties middleware set on the request
during the failed attempt, so they can describe a stale snapshot.

The new `retry` action is triggered before each retry, giving
middleware a place to reset that state. An error passed to `next`
rejects the op.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* 📝 Clarify `retry` hook docs

- Explain why the example captures the snapshot first-write-wins
- Note that snapshot and channels are still the failed attempt's in the hook
- Say "retried" rather than "submitted again"
- Point the 'apply' re-run warning at the retry hook

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* ✅ Test that `retry` resets state before the next apply

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* ♻️ Unset the snapshot and channels before `retry`

The `retry` hook used to see the failed attempt's `snapshot` (with the op
already applied) and `channels`, but an `op` whose fixups had already been
undone. That was inconsistent, and middleware could easily mistake the stale
snapshot for the one the op is about to be applied to.

Unset both before the hook, so it sees the request reset ready for the next
attempt, which fetches the snapshot again and sets new channels.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

1829 of 2014 branches covered (90.81%)

6 of 6 new or added lines in 1 file covered. (100.0%)

3662 of 3737 relevant lines covered (97.99%)

1086.23 hits per line