fix(app): coalesce Den sync requests

[reachjalil]

Problem

The provider auto-sync hook prevented overlapping network requests with an in-flight boolean. That guard also discarded every Den settings-change event received while a request was running. Switching organizations at the wrong moment could therefore leave providers and cloud MCP state on the previous settings until the periodic interval fired.

State and ordering contract

• Never run more than one reconciliation at a time.
• While one is running, retain one pending pass for the newest settings state.
• Coalesce a burst into one immediate follow-up, using the latest reason.
• Cancel pending work on sign-out or unmount.
• A failed pass must release the runner and allow already-pending current state to reconcile.

Implementation

• Replaced the drop-on-in-flight guard with a small serialized sync runner.
• Each signal updates one pending reason; the drain loop consumes it after the active request settles.
• The hook still keeps the latest sync closure without restarting its interval on render.
• Cancellation clears pending work but does not attempt to abort an already-owned request.
• Errors remain owned by the existing stores and do not create an automatic retry loop.

Regression proof

Tests hold the first request open, send several settings changes, and prove:

• no second request starts concurrently;
• the burst produces exactly one follow-up using the newest reason;
• cancellation removes the pending pass;
• a failed first request still releases the queued current-state pass.

Validation

• bun test apps/app/scripts/cloud-provider-auto-sync.test.ts — 3 passed, 0 failed
• pnpm --filter @openwork/app typecheck — passed
• pnpm fraimz --flow den-sync-coalesce — Passed, 4 proof frames plus voiceover coverage

Evidence limitations

The fraimz run is an internal concurrency proof backed by deterministic deferred promises. It is not a live UI recording and does not exercise a production Den tenant or real network latency.

Human review still required

This draft is intentionally not ready to merge until a human reviewer confirms:

• latest-reason coalescing is correct for both provider sync consumers mounted by Settings;
• one follow-up per in-flight window is the desired behavior under sustained settings-event traffic;
• clearing pending work without aborting the active request is correct on sign-out/unmount;
• swallowed promise failures remain correctly surfaced by each owning store;
• a manual organization switch during a deliberately slow sync refreshes current providers and MCP state immediately after the active request settles;
• the branch remains appropriate against the latest dev head.

Scope and mergeability

This is independent from the stale-snapshot identity guard and other remote reliability drafts. It can be reviewed and merged separately.

[vercel]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 12, 2026 4:45pm

[reachjalil]

Review map: independent state and sync reliability drafts

These drafts address separate ownership/order boundaries and are intended to be reviewed independently against dev:

• fix(app): keep Settings connections on the workspace server #2688 — Settings connection actions stay on the selected workspace server
• fix(app): discard stale Den cloud snapshots #2689 — stale Den resource snapshots cannot cross an organization/session switch
• fix(app): coalesce Den sync requests #2690 — settings events received during provider sync coalesce instead of disappearing
• fix(app): cancel stale onboarding redirects #2691 — stale sign-in timers cannot redirect after a newer session or sign-out
• fix(app): ignore stale Den organization refreshes #2692 — only the latest Den organization refresh may mutate state

There is no required merge order. Each PR body includes its own validation, evidence limitations, and a Human review still required checklist. Internal fraimz proofs in this set are test-backed ordering evidence, not live UI recordings.