Skip to content

test(plugin-approvals): pin the lock release in the tenant-admin reverse check - #14750

Merged
os-sales merged 2 commits into
mainfrom
claude/issue-14602-tenant-admin-lock-release-pin
Sep 3, 2026
Merged

test(plugin-approvals): pin the lock release in the tenant-admin reverse check#14750
os-sales merged 2 commits into
mainfrom
claude/issue-14602-tenant-admin-lock-release-pin

Conversation

@os-sales

@os-sales os-sales commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Fixes #14602

The #12775 override-narrowing block's tenant-admin reverse check — "the narrowing is about status, not posture" — proved a strict subset of the platform-admin case it mirrors: recalled status plus the action row, and nothing at all about the record lock. This makes the pair symmetric.

The diff — one file, two lines

packages/plugins/plugin-approvals/src/approval-revise.test.ts, inside reverse check (tenant admin):

-      const { req } = await pendingRequest();
+      const { req, editAttempt } = await pendingRequest();
+      await expect(editAttempt()).rejects.toThrow(/RECORD_LOCKED/);   // pending → locked
       const out = await service.recall(req.id, { actorId: 'org_owner' }, TENANT_ADMIN);
       expect(out.request.status).toBe('recalled');
       expect(await actionsOf(req.id)).toContain('recall');
+      await expect(editAttempt()).resolves.toBeUndefined();            // the #3424 release still happens

Both lines were added, not just the release one. The release assertion alone would have left the case proving a strict subset of what it mirrors one level down: it passes vacuously if the lock never engages for this posture, and "released at the end" is a weaker claim than the locked → released the platform-admin case pins. The pre-condition is what makes released mean released by the recall. Both lines are byte-copies of the platform-admin case four cases above, comment column included.

No product file was touched, and nothing in #12775's ruled behaviour is reopened.

What was measured

Suitepnpm --filter @objectstack/plugin-approvals test, before and after, both Test Files 36 passed (36) / Tests 662 passed (662). The count is identical because both assertions land inside an existing it, so the suite total is not evidence the case ran. The targeted run is:

✓ … > reverse check: the same override actor still recalls the same request while `pending`, and the flag says so 41ms
✓ … > reverse check (tenant admin): admitted on `pending` too — the narrowing is about status, not posture 4ms
 Test Files  1 passed (1)
      Tests  2 passed | 22 skipped (24)

The after-run above is on this PR's head 423a3405d, after origin/main was merged in.

Ablation — the new lines are load-bearing, not decorative. Committed first, then the release assertion was moved to before the recall; the mutation was confirmed on disk (the assertion's in-case line index moved ahead of the recall's) before the run. Predicted direction: red, because the record is still locked at that point. Observed:

AssertionError: promise rejected "Error: RECORD_LOCKED: record 'x1' of 'fin… { …(2) }" instead of resolving
 Test Files  1 failed (1)
      Tests  1 failed | 23 skipped (24)

Restored with git checkout HEAD -- ABS_PATH under an EXIT INT TERM trap; restoration proven by blob hash, e0a7dc8da831ff1ff9fbe837dbd743e3ebd34913 before and after, with git diff HEAD empty. So the lock genuinely engages on this path and only the recall releases it.

Typecheckpnpm --filter @objectstack/plugin-approvals typecheck exit 0. The package's own tsconfig.json excludes **/*.test.ts, so that leg says nothing about the edited file; the leg that does is check:test-typecheck (tsconfig.test.json), and tsc --listFiles -p tsconfig.test.json was used to confirm the edited file is in that program rather than assumed to be. Gate verdict: check:test-typecheck: OK — @objectstack/plugin-approvals's test layer compiles … 8 file(s) / 324 error(s) / 27 pinned signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned).

Gates — derived from the actual change set rather than recalled, via node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands re-run on the merged tree: 29 commands, 25 exit 0. The four non-zero all refuse for an unmet local prerequisite and say so themselves — none is a finding, and none is a pass:

gate exit its own verdict
check-test-completeness.mjs 3 "PREREQUISITE NOT MET — this gate grades a saved turbo run test log, and no log was named… the local reading for this gate is NOT MEASURED"
check:dual-build-cjs-loads 3 "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… ⛔ This is NOT a pass: nothing was measured"
check:i18n 1 "PREREQUISITE NOT MET — the workspace CLI is not built… Nothing was checked"
check:type-check-debt 3 "PREREQUISITE NOT MET … ⛔ This is NOT a pass and NOT a finding: nothing was measured"

CI runs all four against a built tree.

Clause ② — no, re-derived from this diff

git diff -U0 origin/main...HEAD | grep -E '^[+-].*export' returns no matches (grep exit 1, 0 lines). The change set is one path, packages/plugins/plugin-approvals/src/approval-revise.test.ts — a test file that exports nothing to the package entry point, changes no accept/reject behaviour and widens no public surface.

Changeset — none owed; skip-changeset applied

The diff publishes nothing from any package: one .test.ts, excluded from the built output. No empty-frontmatter changeset was added to look complete — check-empty-changeset.mjs rejects exactly that.

Seen, deliberately not touched

src/approval-revise.test.ts:22 imports APPROVALS_HOOK_PACKAGE and never uses it — pre-existing on origin/main, and already carried as frozen debt (test-typecheck-debt.json holds TS6133: 'APPROVALS_HOOK_PACKAGE' is declared but its value is never read. at count 1 for this file). Different defect class from this card, and clearing it would move a ledger; left alone and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8


Generated by Claude Code

…rse check

The `#12775` override-narrowing block's tenant-admin reverse check
("the narrowing is about status, not posture") proved a strict subset of
the platform-admin case it mirrors: `recalled` status plus the action
row, but nothing about the record lock. The platform-admin case pins
`locked → released` around the recall; this makes the pair symmetric with
the same two lines, in the same idiom.

Both lines, not just the release: asserting only the release would pass
vacuously if the lock never engaged for this posture, which is the same
"proves a subset of what it mirrors" weakness one level down.

Test-only. No product change; the ruled behaviour from #12775 is
untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8
@claude claude Bot added the skip-changeset PR has no user-facing published change; bypasses the changeset gate label Sep 2, 2026
@github-actions

github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see
  • a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 7a17f3bf1e48e1e88f8e833a794e37bd40230f17packageMentionDocs.

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

⛔ merge queue 构建失败 — 先分诊,再决定要不要重排

队列构建 33702957362 红了。队列跑的是全量套件(PR 侧 CI 只跑 affected 子集),
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job(日志抽取,best effort):

  • Test Core (1/6) — 失败步骤: Run this shard's tests

    @objectstack/cli:test:  FAIL   integration  test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
      ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
    

↳ 失败原因 是判读的关键:超时Test timed out in … / Hook timed out in …)多半是负载/时序,不是本 PR 的回归;
断言AssertionError: …)才指向真实的行为改变。两者的 FAIL 行长得一模一样,只有这一行能区分。

⚠️ 断言这一侧有一类例外,判据是断言在测什么,不是它是不是 AssertionError 断言的对象是产品行为(一个值、一个形状、一次拒收)⇒ 照上面读:真实的行为改变,去查,⛔ 不要重排掉;
断言的对象是这次实验自身的有效性前提(跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件)⇒ 它跟超时是同一类,同样对负载敏感,重排一次是合法的判别手段。
识别是机械的:断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为(真回归);
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提:它守护的那条不变式当时是绿的,同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量,仍然是时间测量。(⛔ 这只改「怎么读一次红」,不改「哪些测试可以重排」——后者由别处管。)

跨 PR 相同签名(24h,按失败测试文件聚合):

历史信号:

  • 本 PR 过去 24h 无队列失败记录(首次)。
  • 过去 24h 队列共有 35 个失败构建(不含本次)。

分诊清单:

  1. 失败测试在本 PR 改动的包里 → 真回归,修 PR。
  2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」;已有汇总 issue ⇒ flaky/环境问题实锤,去那张 issue 上谈,修好前重排只会再烧一轮全队列。
  3. 两者都不是 → 可能与同组 PR 语义冲突;等前面的 PR 落地或失败出队后再重排一次即可,不要连续重排。

Generated by Claude Code · merge-queue-triage workflow (#4859)

@claude

claude Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Dequeued 01:42Z — not this PR's failure. Re-arming once, and saying why.

The failing check, read rather than assumed

Queue build 33702957362. One job red — Test Core (1/6), step Run this shard's tests:

packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317
  the mirror direction: a reader that is never coming back
    > gives up and exits instead of waiting forever
AssertionError: expected 'SIGKILL' to be null

Failed: @objectstack/cli#test, 65 of 66 turbo tasks successful. check-test-completeness in the same job reports OK (10 of 10 scheduled package(s) reported … 5256 test(s) declared and all accounted for), so the shard ran whole rather than dying early.

This PR's diff is one file — packages/plugins/plugin-approvals/src/approval-revise.test.ts, +3/−1. It cannot reach packages/cli. This is the 9th ejection tonight on the same assertion at the same line, across PRs whose diffs cannot reach that file. Anchor: #14648.

Why the fix is not portable into this PR

PR #14715 fixes it (UNREAD_HARD_CAP_MS becomes the load-independent RUN_TIMEOUT_MS), and the standing rule is to port a fix rather than wait. It touches exactly one file — packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — and #14715 is open and claims it. Porting would put two open PRs on one path and turn this repo's own No other open PR may claim the same single-writer path check red on this PR: trading a probabilistic flake for a certain failure. The port is closed by repo machinery, not by preference.

What happens now

Re-arming auto-merge once. This is this PR's first ejection, and the same one-re-queue allowance #14528 got. The queue is not stalled — #14712, #14718 and #14730 all merged through it in the last half hour — so a second attempt is a real chance rather than a ritual.

One only. A second ejection on this signature is data for #14648, not a third arming. Nothing about this PR changes in the meantime: it is green on 423a3405d and its content is settled.


Generated by Claude Code

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

⛔ merge queue 构建失败 — 先分诊,再决定要不要重排

队列构建 33707742212 红了。队列跑的是全量套件(PR 侧 CI 只跑 affected 子集),
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job(日志抽取,best effort):

  • Test Core (1/6) — 失败步骤: Run this shard's tests

    @objectstack/cli:test:  FAIL   integration  test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
      ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
    

↳ 失败原因 是判读的关键:超时Test timed out in … / Hook timed out in …)多半是负载/时序,不是本 PR 的回归;
断言AssertionError: …)才指向真实的行为改变。两者的 FAIL 行长得一模一样,只有这一行能区分。

⚠️ 断言这一侧有一类例外,判据是断言在测什么,不是它是不是 AssertionError 断言的对象是产品行为(一个值、一个形状、一次拒收)⇒ 照上面读:真实的行为改变,去查,⛔ 不要重排掉;
断言的对象是这次实验自身的有效性前提(跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件)⇒ 它跟超时是同一类,同样对负载敏感,重排一次是合法的判别手段。
识别是机械的:断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为(真回归);
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提:它守护的那条不变式当时是绿的,同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量,仍然是时间测量。(⛔ 这只改「怎么读一次红」,不改「哪些测试可以重排」——后者由别处管。)

跨 PR 相同签名(24h,按失败测试文件聚合):

历史信号:

  • ⚠️ 本 PR 过去 24h 已在队列失败 1 次(不含本次)。 内容未变而反复失败 ⇒ 高度怀疑 flaky 测试或与同组 PR 的语义冲突,重排不解决。
  • 过去 24h 队列共有 42 个失败构建(不含本次)。

分诊清单:

  1. 失败测试在本 PR 改动的包里 → 真回归,修 PR。
  2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」;已有汇总 issue ⇒ flaky/环境问题实锤,去那张 issue 上谈,修好前重排只会再烧一轮全队列。
  3. 两者都不是 → 可能与同组 PR 语义冲突;等前面的 PR 落地或失败出队后再重排一次即可,不要连续重排。

Generated by Claude Code · merge-queue-triage workflow (#4859)

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

Labels

size/xs skip-changeset PR has no user-facing published change; bypasses the changeset gate tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[finding] plugin-approvals after #12775: the tenant-admin reverse check never asserts the lock release

2 participants