Concurrent workout edits need a record-level conflict contract. Separate the coach’s prescription from what the client performed, identify the exact set being edited and decide what happens when an update was based on an older revision. A successful network response should never be the only indication of which change won.
Prerequisites are stable session, exercise and set identifiers; canonical units; an assignment or prescription version; and server-side access checks. A list index is not a durable set identity. Reordering exercises or inserting a warm-up set must not redirect an offline edit to another record.
Separate planned work from performed evidence
A coach changing next week’s load should edit a future prescription. A client correcting today’s logged repetitions should edit performed data. If both interfaces write a field called reps on the same object, clarify whether it means target or completed repetitions before implementing a merge strategy.
| Field | Meaning | Conflict question |
|---|---|---|
| targetReps | Assigned prescription | Does the edit apply to future sessions? |
| performedReps | Client log | Who can correct an accepted entry? |
| weightKg | Canonical performed load | Does the revision still match? |
| prescriptionVersion | Historical context | Which plan did this session follow? |
The worksheet is a proposed schema boundary. The reviewed UltraFit360 hook defines workout-session and set-log request shapes, but the inspected range does not establish optimistic concurrency control. A TypeScript response interface cannot guarantee that a backend rejects stale writes.
Use a stale-update response that preserves both intents
PATCH /sets/fictional-set
{ "performedReps": 9, "expectedRevision": 4 }
409 Conflict
{ "currentRevision": 5, "current": { "performedReps": 10 } }This is an illustrative API contract, not an existing endpoint response. The server compares the expected revision as part of the update. If the revision differs, return enough authorized current state for the caller to decide whether to retry, retain its draft or discard it. Avoid a blind automatic retry that simply overwrites the accepted revision.
In a synthetic race, a coach corrects revision 4 to ten repetitions, producing revision 5. An offline client later submits nine repetitions based on revision 4. The product can show both values and ask for an explicit correction, or apply another documented authority rule. Last-arrival-wins is a choice, not an inevitable property of synchronization.
Make optimistic UI respect server authority
TanStack Query documents optimistic update and rollback patterns. Use them for immediate feedback while retaining the server’s accepted revision as the source of confirmation. A pending badge and local draft can help distinguish a visible edit from a durable shared result.
TanStack Query: optimistic mutations and rollback
Scope cache keys by account, session and relevant view. After an accepted change, update or invalidate the set list, exercise summary and any dependent totals. On a conflict, restoring an entire old session snapshot can erase another accepted edit; reconcile the affected record or refetch the authoritative state.
Exercise the awkward transitions
Build fixtures for coach and client editing the same field, independent sets, a reordered exercise list, duplicate submission and access revoked before retry. Confirm that a client’s unsent draft remains associated with its original account after sign-out. Keep notes and timestamps with the accepted revision where needed to explain a correction.
No concurrent product API test was executed here. The deliverable is a proposed request/result contract and authority worksheet to implement and verify against the actual database. Keep completed workout history stable even when future prescriptions change, so resolving an edit does not rewrite what the client originally followed.
Field-level merging is reasonable only when the edits are independent under the domain model. A changed load and repetition count may jointly describe one performed set, so merging them automatically can create a combination neither person entered. Decide the atomic editing unit and retain accepted revisions. Test both a same-field conflict and different-field edits before enabling automatic merges. The conflict interface should make the accepted record visible while keeping the local draft available for deliberate comparison.
Workout program versioning software
Bring one client-to-coach workflow, current data contract and acceptance constraint to discuss a bounded fitness product build or integration pilot.
Explore health fitness app development
How should concurrent coach and client set edits be reconciled?
Keep performed logs separate from prescriptions and reject or reconcile stale updates using an explicit record revision and authority policy.
Can a client-side revision check prevent all lost updates?
No. The authoritative server update must enforce the expected revision; a preflight read alone can race.