You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039
Docs-only finding, filed unassigned. Surfaced by the Docs Drift Check on #14035, not ignored — that bot flagged a release-owned page, the guardrail says such a page is read-only and a genuine error should become an issue rather than an edit, so this is that issue.
content/docs/releases/ is release-owned and I did not touch it.
The two entries
Both are in content/docs/releases/v17.mdx, i.e. the same release:
Line 2072-2073 (#4366, under New capabilities (backend)):
…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user" (#4366).
runAs: 'system'create_record stamps all three ADR-0118 columns (#5494) — organization, owner and creator are non-NULL.
Neither is false on its own — the problem is what they say together
They describe two different things and each is accurate in isolation: #4366 is about the actor label, #5494 is about the stamped columns.
But the first is stated unqualified — "a runAs: 'system' flow's writes are audited as svc:flow:<flowName>" reads as the general rule for every system-elevated run. What actually ships (and what #5494 settled, later in the same release) is that the triggering user is carried through; svc:flow: is the fallback for a run that genuinely resolves no user, such as a schedule.
packages/services/service-automation/src/runtime-identity.ts:189 says it in as many words:
#5494 — elevation is not anonymity. When the trigger resolved a user …
So a reader working through v17's notes front to back meets the unqualified version ~800 lines before the entry that refines it, with nothing linking the two. A reader who stops at the first one comes away believing system elevation costs you the operator in the audit trail.
Why this is worth a card and not a shrug
This is the same false belief #14011 is fixing in the contract prose, in a page with considerably more readers than a .d.ts.
#14011 exists because that belief is load-bearing in the wrong direction: downstream it got written into a security adjudication as the explicit stop-condition — "if elevation erases the operator, stop and report a fork, because the requirement demands 谁修改了什么都要有日志可查". The correct design was one measurement away from being abandoned on a false premise. It survived only because the investigating agent measured instead of reading.
The contract-prose half is being corrected on #14035. This is the other place the same concept lives.
Suggested handling
The release page is a historical record, so the fix is not to rewrite the #4366 entry into what #5494 later made true — that would falsify what #4366 shipped. Two options that keep the record honest:
I lean to 1 because these two sit in the same release — this is not old notes describing an older behaviour, it is one page whose earlier row a later row on the same page supersedes. But release-note policy is the release process's call, not a downstream reporter's, so I am not proposing a PR.
Not a defect, for the record
The other row the drift check flagged on #14035 — content/docs/releases/v15.mdx:863 ("Flow-type actions now receive the caller's identity as a real AutomationContext (runAs: 'user' flows evaluate RLS as the caller)") — I checked and it is correct as written. It was listed because it names the AutomationContext symbol, which is precisely the precision-first behaviour the bot advertises. No action there.
Context: #14011, #14035. Filed from the downstream steedos-labs/hotcrm-heimao seat.
Docs-only finding, filed unassigned. Surfaced by the Docs Drift Check on #14035, not ignored — that bot flagged a release-owned page, the guardrail says such a page is read-only and a genuine error should become an issue rather than an edit, so this is that issue.
content/docs/releases/is release-owned and I did not touch it.The two entries
Both are in
content/docs/releases/v17.mdx, i.e. the same release:Line 2072-2073 (#4366, under New capabilities (backend)):
Line 2860-2861 (#5494):
Neither is false on its own — the problem is what they say together
They describe two different things and each is accurate in isolation: #4366 is about the actor label, #5494 is about the stamped columns.
But the first is stated unqualified — "a
runAs: 'system'flow's writes are audited assvc:flow:<flowName>" reads as the general rule for every system-elevated run. What actually ships (and what #5494 settled, later in the same release) is that the triggering user is carried through;svc:flow:is the fallback for a run that genuinely resolves no user, such as a schedule.packages/services/service-automation/src/runtime-identity.ts:189says it in as many words:So a reader working through v17's notes front to back meets the unqualified version ~800 lines before the entry that refines it, with nothing linking the two. A reader who stops at the first one comes away believing system elevation costs you the operator in the audit trail.
Why this is worth a card and not a shrug
This is the same false belief #14011 is fixing in the contract prose, in a page with considerably more readers than a
.d.ts.#14011 exists because that belief is load-bearing in the wrong direction: downstream it got written into a security adjudication as the explicit stop-condition — "if elevation erases the operator, stop and report a fork, because the requirement demands 谁修改了什么都要有日志可查". The correct design was one measurement away from being abandoned on a false premise. It survived only because the investigating agent measured instead of reading.
The contract-prose half is being corrected on #14035. This is the other place the same concept lives.
Suggested handling
The release page is a historical record, so the fix is not to rewrite the #4366 entry into what #5494 later made true — that would falsify what #4366 shipped. Two options that keep the record honest:
svc:flow:is what a run resolving no user falls back to, and that Automationcreate_recordunderrunAs:'system'inserts rows withowner_id/organization_id/created_byall NULL — records born untouchable even by admin #5494 (later in this same page) carries the triggering user through. Smallest change, keeps both entries accurate as written.I lean to 1 because these two sit in the same release — this is not old notes describing an older behaviour, it is one page whose earlier row a later row on the same page supersedes. But release-note policy is the release process's call, not a downstream reporter's, so I am not proposing a PR.
Not a defect, for the record
The other row the drift check flagged on #14035 —
content/docs/releases/v15.mdx:863("Flow-type actions now receive the caller's identity as a realAutomationContext(runAs: 'user'flows evaluate RLS as the caller)") — I checked and it is correct as written. It was listed because it names theAutomationContextsymbol, which is precisely the precision-first behaviour the bot advertises. No action there.Context: #14011, #14035. Filed from the downstream
steedos-labs/hotcrm-heimaoseat.