Summary

Temporarily disable stale data checking for autosave-enabled collections and globals to prevent false positives from race conditions.

Problem

When autosave is enabled (collections or globals), rapid edits trigger a race condition between autosave completion and onChange debounce, causing the "Document Modified" modal to incorrectly appear for the same user.

Approaches Considered

Several approaches were explored to distinguish between a user's own autosaves and another user's changes:

1. Track autosave queue status: Add an autosaveQueued flag to skip stale checks when autosave is processing. This fixes the false positive (same user seeing their own changes as stale), but creates false negatives in multi-user scenarios. When User 2 starts typing, their own autosave could queue before onChange fires, causing the check to skip even when User 1 has legitimately modified the document.

2. Grace period after page load: Skip stale checks for X seconds after opening a document. This is an arbitrary time-based workaround that doesn't address the root cause and has unreliable edge cases (what if autosave takes longer than the grace period?).

3. Shared queue between Form and Autosave: Have both components use the same task queue to coordinate timing. While architecturally sound, this requires a major refactor and still doesn't solve the fundamental issue that autosave's potentially shorter debounce causes it to queue before onChange.

4. Immediate stale check without debounce: Perform the stale data check directly in the Form component on every keystroke instead of waiting for the debounced onChange. This could work but duplicates onChange logic, requires watching formState changes without debounce, and could cause performance issues.

5. Combined approaches: Mix multiple approaches (e.g., autosaveQueued + grace period). This adds significant complexity without fully solving the problem - still vulnerable to edge cases and race conditions.

All approaches were flawed because they tried to work around the timing issue rather than addressing the fundamental problem: we can't reliably distinguish between a user's own autosaves and another user's changes without tracking who made each change.

Solution

Disable stale data checking when:

• Collections: versions.drafts.autosave is configured
• Globals: versions.drafts.autosave is configured

Autosave-enabled documents already have frequent saves for conflict resolution.

Future Work (v4.0)

Implement proper updatedBy tracking to compare current user vs last editor. This is the correct solution but requires breaking schema changes.

Changes

• Skip stale check when hasAutosaveEnabled(docConfig) returns true

Fixes #15803