Re: [PR] fix(runtime-host): separate the persisted grant record from the authority it derives [maka]

["Astro-Han (via GitHub)" <gi...@apache.org>]

Astro-Han commented on PR #4427:
URL: https://github.com/apache/maka/pull/4427#issuecomment-5491359486

   Both findings were right. Rebased onto current `main` and rebuilt. Finding 2 is fixed as prescribed; finding 1 is fixed differently.
   
   **Finding 2.** Verified first: replaying the real 85-file change list of #4351 through the planner gave `stateRootCompat = false`. `protocol/operations.ts` is now in the trigger, pinned by a planner test that fails when it is removed. Same input now gives `true`, with `full = false`.
   
   **Finding 1.** Your diagnosis holds on every point, including the sharpest one: fail-open decode plus a `host.status`-only assertion means the alarm was structurally incapable of firing.
   
   I did not restore fail-closed, because it prices in a cost the prescription does not name. This file sits at `resolveRootControlNamespace()/<rootId>/runtime-host-access.json` — no version segment. A stable app, a Nightly CLI and a rolled-back build read the same file, and vocabulary evolution never bumps `schemaVersion` (#4351 did not). Under fail-closed, any release adding an operation key bricks every older build installed beside it. That is two release channels coexisting, not an edge path.
   
   Both fail-closed and my fail-open were symptoms of one defect your comment made visible: the array was simultaneously the record and the authority.
   
   They are separate now. `StoredAccessCredential.grants` is the record; `effectiveOperationGrants` derives the authority per decode and never writes back. A grant this build cannot serve is excluded from the authority and kept in the record.
   
   Against your specific objections:
   
   - **Durable loss** — gone. The key stays on file, so adding a forgotten entry later restores the grant on next start. Qualification now asserts the reading build can account for every stored grant, so a retired key with no entry fails the candidate.
   - **Registry as sole exception** — kept. `replace` and `release` are the only rewrites, and a `replace` naming no successor now fails to compile.
   - **The test blessing an arbitrary unregistered release** — gone; the suite asserts the opposite.
   - **The guest exception** — gone, by restructuring rather than removal: a guest's record was never authoritative, so it is one derivation rule among three. The same change put a capability provider under its own policy, which decoding had been filtering through the remote-owner allowlist.
   
   No per-grant semantic probes were added. The assertion is one question asked of the reading build; the fixture does not know the registry exists.
   
   One limit, since my earlier description overreached: this catches a retired key with no entry, not a key that stays valid while its meaning widens. That stays a human declaration, as you said.
   
   Separately, found while verifying: the forward-roll baseline is whichever Nightly the registry currently tags, unfenced against the commit under test. The quiet failure is the bad one — if that Nightly already contains the migration under test, both sides speak the same vocabulary and it passes without crossing a version boundary. Pre-existing, exposure widened here, tracked in #4447.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org