Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Concurrent writes: optimistic concurrency (version + If-Match → 412) so a co-editor's save is never lost silently

Chiusa
  • Qualcosa non va?
#561 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #562 di @silverbackdan — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php, symfony
Ambito
api, backend, databases

Direzione di ricerca

Start by tracing LastWriteResolver and how writable resources are serialized and updated; the payload does not name source files or tests. Check how versions could cover drafts, published resources, publish, and order changes, then review ETag and CORS handling. Done means writes with stale If-Match return 412 with the current resource, while writes without it continue to work.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Two admins saving the same field of the same resource at the same moment lose one save silently. Found while porting the TipTap co-editing reference (components-web-app/cwa-nuxt-module#429) with @cwa/nuxt 2.0.0-alpha.28 and this bundle at 2.0.0-alpha.35.

Reproduced

One HtmlContent draft open in two tabs (each with its own X-CWA-Client-Id), both typing in the same editor:

  • The two PATCHes went out 1 ms apart, and both returned 200.
  • Each body was the tab's whole html, built from what that tab had before the other's save, so the second commit replaced the first. Neither client can tell that its save was overwritten.
  • In one run the PATCH responses carried lastWrite.at 17:00:36.235 (A) and 17:00:36.219 (B), and the stored html was A's.

Why the module can't settle it alone

lastWrite.at is stamped the first time the resource is serialised in the request (LastWriteResolver), not in commit order. With two workers a few milliseconds apart, the save that commits last can carry the earlier time. The module drops an update older than its stored copy, so a tab can drop the update that actually won and stay out of step with the stored data. That happened on the template stack in 3/3 runs.

Proposal: optimistic concurrency on writes

  • Every writable resource exposes a version that changes on each write. Doctrine's #[ORM\Version] integer would do, or an opaque token. Serialise it, for example in _metadata, and send it as the response ETag.
  • A PATCH (and PUT/DELETE) with If-Match succeeds only if the stored version still matches; otherwise 412 Precondition Failed, with the current resource in the body so the client does not need a second request.
  • Without If-Match, writes behave as now, so non-realtime clients keep working.
  • The version on Mercure updates lets a client order updates by version instead of by lastWrite.at.
  • To decide: whether the version covers draft and published as one resource (the module treats them as one for conflicts), and how a publish (a draft's PATCH that removes the draft) and the order PATCH / /move take part.
  • CORS: expose ETag and allow If-Match for cross-origin apps.

Module side, once released

The module sends If-Match from the stored version on each save. On a 412 it shows the field's existing conflict (Use theirs / Keep mine) with the body as theirs, and Keep mine re-sends with the new version. It orders Mercure updates by version.

Lingua principale
PHP
Stelle
32
Fork
8
Merge medio
56m
PR unite (30g)
164

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di components-web-app/api-components-bundle

Tutte le issue di components-web-app/api-components-bundle

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.