Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#561 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

已经有一个关联 PR 被合并了。

  • #562 来自 @silverbackdan —— 已合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
php, symfony
领域
api, backend, databases

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
PHP
星标
32
派生
8
平均合并
56 分钟
30 天内合并 PR
164

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

components-web-app/api-components-bundle 的其他 Issue

查看 components-web-app/api-components-bundle 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。