[adrian-baker]

What?

useQueue now calls beforeProcess before each task it runs, instead of once before its loop. afterProcess already runs after each task, so the two now pair up for every task.

Why?

Autosave uses the two callbacks to set the form's background processing flag on and off. When a second autosave was queued behind the first, it ran after afterProcess had turned the flag off, and nothing turned it back on. An edit made during that save then wasn't recorded as "modified while processing", the save's response reset modified to false, and the autosave for that edit found nothing to save. The editor's last edit was lost, although the field showed it. Fixes #18348, which has the full sequence.

How?

The beforeProcess check moves to the top of the while loop. Returning false still stops processing and leaves the queue as it was, as it did before the loop. The doc comment on beforeProcess says it's called before each function.

useQueue.spec.tsx covers both: a task queued while another runs gets its own beforeProcess, and a false from beforeProcess stops the task from running. The first test fails without the change, with beforeProcess recorded once instead of twice.

The same change applies unchanged to 3.x, where useQueue.ts is identical. The 3.x fix is #18350, without the spec, because that branch has no browser test project.

🤖 Generated with Claude Code

[jacobsfletch]

Hey @adrian-baker - really appreciate the contribution here. We're actively refactoring the entire useQueue hook in #19203, which should cover this. I added a regression test based on the linked issue's specific repro steps.

The refactor enables background processing when each autosave starts, so queued saves re-enable it after the previous save clears it. Edits made during those saves stay marked as unsaved, so the next autosave picks them up.

[adrian-baker]

Excellent, thank you, I'll keep an eye on #19203.