Recover task save conflicts without overwriting a teammate

Read the save state before troubleshooting

The first diagnostic question is not Did the slider move? It is Did the server acknowledge the intended value? Critical Path displays Local, Saving, Saved, Offline, or Review sync in its shell. Local belongs to the preview experience; it should not be confused with a saved authenticated workspace that another device can load.

Saving means work is in flight or further edits remain queued. Saved means the application received an acknowledgement for the relevant workspace and revision. Offline means changes have not yet been saved to the server; it can represent a failed request rather than proving your entire internet connection is disconnected. Review sync means the app has stopped automatic writes because a conflict or rejection needs attention.

Do not diagnose every failure as the same autosave bug. A task field rejected by validation, a server revision changed in another tab, and a transient network failure need different remedies. Read the visible notice, preserve the work, and identify the category before clearing browser data or changing values repeatedly.

Understand why a conflict is a protective stop

A collaborative workspace can change between the moment you load it and the moment you save. Critical Path sends a base revision with a save. If the server has moved on, it can return a conflict instead of accepting a stale whole-workspace overwrite. HTTP 409 is the general conflict response; the application adds its own comparison and recovery behavior on top.

The client compares the original saved value, your pending value, and the newer server value. Changes to separate supported fields can be combined and retried. When the same field changed differently, the app retains pending work for review and blocks further automatic writes. That pause is preferable to silently choosing one person's edit.

Not every difference is a user conflict. Calendar blocks and other server-owned task fields are deliberately excluded from the browser's editable recovery patch. The goal is to preserve user edits without treating a stale local copy of provider state as authoritative. This is why manually reposting an old full snapshot is not an appropriate recovery method.

Sources: MDN: HTTP 409 Conflict

Worked example: different fields versus the same field

Imagine two fictional tabs opening the same saved task. Its title is Prepare options brief and its allocation is 60 minutes. In tab A, an owner changes the title to Prepare reviewed options brief. In tab B, the owner changes the allocation to 90 minutes. Because those are different fields, the client can compare the original state and combine the edits when the server revision changes.

Now imagine both tabs change the allocation: A sets 90 minutes while B sets 120. The newer value is not automatically more correct. One tab may contain a better estimate; the other may contain a scope change that has not been discussed. The application should stop for review, and the owner should decide which requirement is intended before resubmitting it.

• Write down which tab contains the intended change before navigating away.
• Do not infer correctness from which tab was edited most recently.
• Coordinate with a teammate when the change affects scope, owner, or delivery expectations.

Recover in a deliberate sequence

When the notice says Your changes need review, stop editing unrelated records in that tab. Choose Download recovery copy first. The exported JSON contains the visible workspace state and, when present, pending recovery information. Keep it in a private location because task titles, descriptions, people, and other workspace content can be sensitive.

Next choose Load saved version only when you are ready. Its confirmation explicitly says that loading the latest server version discards this tab's pending edits. The app does not currently provide a field-by-field merge dialog or a guaranteed one-click import of the recovery file. Use the copy as a reference for reviewing and manually reapplying only the intended changes.

After the server version loads, compare the affected fields with your notes or recovery copy. Decide what should survive, re-enter a small set of edits, and wait for Saved. Verify the changed fields before moving on. Avoid uploading the whole recovery file into an arbitrary JSON viewer; private workspace data should remain in approved tools.

1. Keep the affected tab open and read the exact notice.
2. Download recovery copy and confirm a private file was produced.
3. Identify the intended values and coordinate overlapping changes if needed.
4. Choose Load saved version and accept the discard warning only after preserving your edits.
5. Reapply the chosen changes manually to the current server state.
6. Wait for Saved and verify the result.

Handle offline saves without creating a second conflict

If the state is Offline rather than Review sync, keep the tab open while connectivity returns. The application retries failed saves with backoff and exposes Retry save in the notice. Use that control after checking the connection; do not open several new tabs and make the same correction in all of them.

A browser recovery copy is retained in sessionStorage when available. MDN documents that this storage is tab-scoped, normally survives reloads, and is cleared when the tab or window closes. Browser policies can also prevent persistence. Therefore a tab-local draft is a convenience, not a device-loss backup or a guarantee that closing and reopening will recover pending work.

Critical Path warns when it cannot retain a recovery copy and limits its pending draft size. If the warning appears, preserve changes with the download control before leaving. An in-memory value that looks correct can still be lost when the page is destroyed. Do not clear cookies, site storage, or browser data as the first troubleshooting step while unsaved work remains.

Sources: MDN: sessionStorage lifetime and limits

Check a capacity change without blaming the calendar

For a weekly-capacity change, confirm that you are in the intended authenticated workspace and editing your own capacity. Change the value once and observe the save state. The current implementation separates a capacity-only save from calendar reconciliation, so a calendar authorization problem should not be treated as a reason to repeatedly move the slider.

After Saved, navigate away and return or inspect the saved state from a fresh view. Do not do that first if the tab reports pending or conflicting work. If the value reverts, record the value requested, the value later shown, approximate time, workspace context, and visible save status. These observations distinguish a rejected save from reading a different account or a subsequent edit.

Keep support evidence focused. A redacted screenshot of the notice and affected control is often more appropriate than a full workspace export. Never include passwords, session cookies, provider credentials, or private calendar feed URLs. If a private recovery file is needed, agree on an approved transfer method rather than attaching it to a public issue.

Reduce avoidable conflicts without forbidding collaboration

Use one active editing tab for a focused session when practical. Let a teammate know before changing shared policies or substantially reorganizing the same task set. These habits reduce collisions but do not replace revision protection; ordinary concurrent work should remain possible.

Treat the recovery notice as a decision point. It is not an instruction to keep retrying until the server accepts your version. Preserve the pending work, understand the newer state, and apply the intended difference. The goal is a trustworthy shared workspace, not a successful overwrite at any cost.

Common questions