Handle Shape Evolution Conflicts Across Transactions

Problem

Optimistic transactions can modify data shape freely:

• Adding new fields
• Deleting fields
• Changing relationships

If server state changes underneath pending optimistic transactions (e.g., removes fields, changes types, remaps IDs), optimistic assumptions can be invalidated.

Without structured handling, this causes:

• Silent UI desync
• Transaction failures with unclear cause
• Data inconsistencies visible to users

Proposed Solution

Implement immediate rollback of optimistic transactions upon detection of shape conflicts during server sync.

Behavior

• Track fieldsTouched and objectsTouched per transaction.
• On incoming server sync, compare optimistic deltas against confirmed server truth.
• If a conflict is detected (field missing, field type changed, critical link remapped):
  • Mark the transaction invalid.
  • Roll back all optimistic changes originating from the invalid transaction.
  • Optional: notify developer through a transaction failure callback.

Developer Responsibility

• If logically related changes must succeed or fail atomically, developers must group them into a single explicit transaction.
• Separate transactions are independent and may be invalidated individually without preservation of cross-transaction assumptions.

No Complex Recovery

• No partial reconciliation or field-level merges.
• No hidden conflict resolution.
• Clean rollback of entire transaction scope only.

Constraints

• Conflict detection is shallow: only field existence/type checked, not full semantic reconciliation.
• Tempid remapping for foreign key fields is handled separately at ID resolution stage.
• System guarantees mechanical consistency, not logical intent preservation unless explicitly modeled by developer.

Future Work

• Fine-grained field-level dependency tracking if future applications demand more sophisticated partial conflict recovery.
• Potential tooling for analyzing field evolution patterns across optimistic transactions in development mode.

No files, tests, or entry points are named. Start by locating the optimistic transaction tracking and server-sync paths, then trace how fieldsTouched and objectsTouched could be compared with confirmed state. Done means detected shape conflicts invalidate and fully roll back the affected transaction, with any failure callback behavior covered.