Skip to content

meta overlays: a deleted overlay stays in the /meta listing though dispatch correctly 404s (#4432 residual) #5079

Closed
#6687
Closed
meta overlays: a deleted overlay stays in the /meta listing though dispatch correctly 404s (#4432 residual)#5079
#6687
Assignees
os-zhuang
Labels
bugSomething isn't workingpm:dispatchedpm:queue

Description

@baozhoutao
baozhoutao
opened on Aug 4, 2026

Follow-up to #4432, verified on main @ a1a855a28 (the rc.3 train tip) as part of the #3909 G1 regression pass.

The two headline harms of #4432 are fixed. Both type spellings now address one namespace (/meta/actions/x and /meta/action/x both report type=action), an overlay no longer shadows the code-authored listing (13 items before and after a PUT), and a saved overlay is dispatchable immediately (#4521). Confirmed by re-running the original repro.

One branch of the original report survives: after DELETE, the listing still returns the deleted overlay while dispatch correctly refuses it.

Repro (clean cycle, fresh name)

PUT    /api/v1/meta/action/rg_clean            → 200
  GET  /api/v1/meta/action  → rg_clean listed (1)
  POST /api/v1/actions/showcase_task/rg_clean  → 200   ✅ dispatchable

DELETE /api/v1/meta/action/rg_clean
  → 200 {"success":true,"reset":true,"seq":4,
         "message":"Customization overlay deleted — action/rg_clean reset to artifact default. [seq=4]"}

  GET  /api/v1/meta/action  → rg_clean STILL listed (1)   ❌
  POST /api/v1/actions/showcase_task/rg_clean  → 404      ✅ correctly gone

The delete is real — it reports reset: true with a sequence number, and the dispatch path honours it one request later. Only the listing disagrees.

It is not storage: sys_metadata holds no rg_* row, and rg_clean does not appear in dist/objectstack.json. So the listing is serving a cached/registry view that the delete path updates for dispatch but not for enumeration — the mirror image of #4521, which fixed the same seam in the write direction (saved overlays became immediately dispatchable).

Why it still matters

An admin who removes a customization sees it still listed and reasonably concludes the delete failed — the exact confusion #4432 was filed about, just moved from the write side to the read side. Anything that enumerates metadata to decide what exists (Studio's authoring surfaces, a sync/export, a reconciliation job) reads a surface that includes a deleted item.

Expected

DELETE invalidates the enumeration view in the same step it invalidates the dispatch view, so list / get / dispatch agree immediately — the "every surface in agreement" clause of #4432.

Found during the #3909 rc.3 regression pass (G1).

Activity

  1. baozhoutao commented on Aug 4, 2026

    @baozhoutao
    baozhoutao
    on Aug 4, 2026
    ContributorAuthor

    Found during the v17 verification tracked in #3909 (section G1 regression).

  2. xuyushun441-sys
    added
    bugSomething isn't working
    domain:engine
    on Aug 4, 2026

  3. baozhoutao commented on Aug 4, 2026

    @baozhoutao
    baozhoutao
    on Aug 4, 2026
    ContributorAuthor

    Rolled up in #5145 (the rc.2/rc.3 verification rollup — supersedes the closed #4482).

  4. xuyushun441-sys
    added
    pm:queue
    on Aug 4, 2026

  5. os-zhuang commented on Aug 4, 2026

    @os-zhuang
    os-zhuang
    on Aug 4, 2026 – with Claude
    Contributor

    串行注记(PM 循环第 4 轮,会话 session_01Pbu27iNUfQCHeuS551Rqo7):本轮不派,两个原因:(1) 与 #5086(同批候选)疑似同触 protocol/meta 写删路径,串行;(2) 「删除更新了 dispatch 视图却没更新枚举视图」的形状高度疑似 listCache/registry 失效家族(#5109/#5218/#5251 三单刚清账的同一字段),而 #5251(降级缓存策略)正在合并队列 —— 本单必须基于其合并后的 readCachedList()/degraded 形状工作。#5086 落地 + #5251 合入后即派;届时给 dev 的线索:对照 applyRepoEvent/invalidateForForeignWrite 检查 overlay DELETE 路径是否漏调失效,并留意 #4521 修写方向时的对称缝。

    Generated by Claude Code

  6. os-zhuang commented on Aug 4, 2026

    @os-zhuang
    os-zhuang
    on Aug 4, 2026 – with Claude
    Contributor

    串行注记更新(PM 循环第 4 轮,会话 session_01Pbu27iNUfQCHeuS551Rqo7):#5086/#5251 均已合入,但本单继续排 #5259 之后 —— 新发现的 #5259(unregister() 先失效后删库,窗口内并发 list() 把已删项按完整读重新缓存 30s)与本单现象(DELETE 后枚举视图仍列出、dispatch 已 404)高度疑似同根或强相关,#5259 的 dev 正在飞。届时派发本单时第一步是:在 #5259 修复后的 main 上重跑本单复现 —— 若已消失则本单以验证收尾关闭;若仍在,排查 overlay DELETE 路径(deleteMetaItem)是否漏删 registry 条目 / 漏调失效(#4521 写方向修复的镜像缝)。

    Generated by Claude Code

  7. os-zhuang
    added
    domain:engine-core
    and removed
    domain:engine
    on Aug 5, 2026
  8. hotlong
    added
    domain:metadata
    and removed
    domain:engine-core
    on Aug 7, 2026

  9. hotlong commented on Aug 7, 2026

    @hotlong
    hotlong
    on Aug 7, 2026 – with Claude
    Contributor

    迁移:domain:engine-core → domain:metadata(维护者 2026-08-07 批准拆分;座位贴 #6367,SKILL PR #6370)。落点证据:DELETE /meta/action 后 overlay 仍留在 GET /meta 列表而 dispatch 正确 404 —— 元数据枚举/注册表失效接缝(#4432 残留)。全量分类审计 49 卡三判,本卡 MOVE/high。分诊会话:session_01BickTBKm2JYSNnrtPT8ysa。

    Generated by Claude Code

  10. os-zhuang
    added
    pm:dispatched
    on Aug 8, 2026
  11. os-zhuang
    self-assigned this
    on Aug 8, 2026

  12. os-zhuang commented on Aug 8, 2026

    @os-zhuang
    os-zhuang
    on Aug 8, 2026 – with Claude
    Contributor

    Claim: PM loop round 1+ (domain:metadata seat, sticker #6367; batch raised to 5 by maintainer instruction 2026-08-08 「并发加到5」)
    Session: session_01W6bLax4KMrSfnE1ydFU8Dw
    Branch: claude/issue-5079-delete-overlay-listing
    Worktree: objectstack-issue-5079
    Domain: domain:metadata
    File surface: packages/metadata-protocol/src/protocol.ts getMetaItems / deleteMetaItem regions only (~:3284, ~:10514) + (if the seam proves to live there) packages/metadata* registry/cache invalidation files + tests + one .changeset/*.md
    Serial constraints cleared: the two serial gates recorded on this thread are both landed — #5086/#5251 (2026-08-04) and #5259 closed completed 2026-08-04T15:11:08Z (the unregister() re-cache window). Per the standing note, step one of this dispatch is re-running the repro on today's origin/main; if the residual is gone, the card closes by verification (premise_still_valid: false). Same-file note: #6479 in flight on updateData (:5743), #6285 dispatched this round on assertRuntimeAuthoringRules (:2405) — maintainer explicitly authorized region-disjoint parallel authorship on this hot file (2026-08-08); landings stay serial through the merge queue. Region confinement is a stop-on-breach term for all three. ⚠️ #6602 (untriaged finding) names the same getMetaItems org-hydration loop — if this fix and that finding turn out to be one seam, report it; do not absorb #6602 silently.

    Generated by Claude Code

  13. os-zhuang commented on Aug 8, 2026

    @os-zhuang
    os-zhuang
    on Aug 8, 2026 – with Claude
    Contributor

    Review verdict: ACCEPT — PM domain:metadata seat, session session_01W6bLax4KMrSfnE1ydFU8Dw.

    PR #6687. What shipped, and what the dev's measurement corrected:

    • The issue's premise held, and was wider than reported: on today's main, after DELETE the single-item GET also served the deleted body, and the "dispatch correctly 404s" in the issue title was a coincidence — the declaration was still resolved from the stale registry entry (ADR-0066 D4 judged against a nonexistent declaration); only the handler registry had been correctly dropped. Both corrections are recorded in the PR body per the corrected-premise discipline.
    • Root cause at the producer: meta overlay: a just-saved overlay is listed but not dispatchable for a short window — a cache between saveMeta and resolveRouteActionDeclaration lags the write #4521's write-through parks runtime-created items under SchemaRegistry's plain key; removeRuntimeShadow deliberately declines when no packaged artifact remains, so nothing ever removed the entry — one seed, three stale surfaces (LIST / GET / declaration gate). Fix: restoreArtifactRegistryView walks artifact → MetadataService baseline (via the diagnosed read, ADR-0110 D3: an outage stops the walk) → retires the plain-key entry via the new SchemaRegistry.removeOverlayEntry, which refuses genuine artifacts by getArtifactItem's own predicate.
    • Reverse verification red in the predicted direction (3 protocol-level + 5 registry-level), boundary pins green on both sides; real-machine verification on a fresh showcase boot twice, including the artifact-backed reset non-regression.
    • Cross-domain surface (packages/objectql/src/registry.ts + its pin suite; test-only mirror block in packages/runtime) is accounted file-by-file in the PR body; a cross-seat notice with a veto window goes to the domain:engine-core seat before landing.
    • Out-of-scope discipline held: the org-blindness observation is attached to An org-scoped overlay row reaches the process-wide SchemaRegistry on unscoped kernels — both the write-through and the read hydration gate only on environmentId, never on org #6602 (no duplicate card), the plugin-security consumer-side workaround is left in place with its dual role explained.

    Next: CI convergence check, then ready + merge queue.

    Generated by Claude Code

  14. os-zhuang
    closed this as completedin #6687on Aug 8, 2026

  15. os-zhuang commented on Aug 8, 2026

    @os-zhuang
    os-zhuang
    on Aug 8, 2026 – with Claude
    Contributor

    Landing confirmed — PR #6687 merged as 114e72795 (verified on origin/main). Deleting a runtime-created overlay now retires its registry entry, so list / get / dispatch answer identically immediately after DELETE, and the declaration gate no longer resolves deleted declarations. — domain:metadata PM, session session_01W6bLax4KMrSfnE1ydFU8Dw

    Generated by Claude Code

  16. os-zhuang
    added a commit that references this issue on Aug 9, 2026

    test(runtime): main 新增的 #5079 ARTIFACT-backed 用例改走 OS_METADATA_WRITAB…

    7dfe91b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingpm:dispatchedpm:queue

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions