mirror of
https://github.com/dohooo/helmor.git
synced 2026-09-22 16:40:02 +08:00
6a80be25b1
The F-B lockout (live-verified in class1 run #2): provision rotated HELMOR_COMPANION_TOKEN via 'secret put' BEFORE deploy/verify, and the desktop only receives the token on the terminal 'deployed' line — so any mid-run failure stranded the Worker on a NEW token the desktop never saw (desktop/Worker/container three-way mismatch, existing teams only). Fix (architect-approved failure matrix in class4-design.md par.2): reuse-or- generate. On a RE-provision the frontend passes the desktop's stored admin token (getTeamAdminToken) -> deploy_team_cloud forwards it to the script as HELMOR_EXISTING_COMPANION_TOKEN (env only, never logged) -> provision reuses it, so 'secret put' writes the value the desktop ALREADY holds. After that point every failure row has desktop == Worker; a pre-existing F-B mismatch even self-heals (the put forces the Worker back to the desktop's value). The step ORDER is deliberately unchanged: rotate-then-put stays for FRESH teams (nothing held -> nothing to lock out; 'wrangler secret put' before the first deploy also auto-creates the draft Worker, a load-bearing behavior both rollouts exercised). F-C's 401 propagation grace and destroy-warm keep their semantics — on the reuse path the propagation window physically disappears (same value), on the fresh path they still do their verified job. Forced rotation remains reachable via Leave team -> Create team (clears the token). resolveAdminToken extracted pure (cloud/scripts/admin-token.ts) with unit tests; the frontend wiring is pinned by team-create-flow tests (red-verified against the unwired call).
36 lines
1.6 KiB
TypeScript
36 lines
1.6 KiB
TypeScript
// Companion/admin token decision for provision-team.ts (round6 P1-4b).
|
|
// Extracted as a pure function (same pattern as broker-key.ts /
|
|
// verify-live.ts) so the reuse-or-generate rule is unit-testable in
|
|
// cloud/test/admin-token.test.ts.
|
|
|
|
export type AdminTokenDecision = {
|
|
/** The token `secret put` writes and `emitDeployed` returns. */
|
|
token: string;
|
|
/** True when the desktop's existing token was reused (no rotation). */
|
|
reused: boolean;
|
|
};
|
|
|
|
/**
|
|
* Reuse-or-generate (P1-4b): the desktop passes its currently-held companion
|
|
* token via `HELMOR_EXISTING_COMPANION_TOKEN` on a re-provision; when present,
|
|
* provision REUSES it instead of rotating.
|
|
*
|
|
* WHY this kills the lockout (F-B): the desktop only learns a token from the
|
|
* terminal `deployed` line, so under rotate-first any mid-run failure left the
|
|
* Worker on a new token the desktop never received. With reuse, `secret put`
|
|
* writes the value the desktop ALREADY holds — after that point every failure
|
|
* row of the matrix has desktop == Worker (and a pre-existing mismatch
|
|
* self-heals, because the put forces the Worker back to the desktop's value).
|
|
* Rotation is deliberately preserved on the FRESH path (nothing held →
|
|
* nothing to lock out) and remains reachable for an existing team via
|
|
* Leave team → Create team, which clears the stored admin token.
|
|
*/
|
|
export function resolveAdminToken(
|
|
existingRaw: string | undefined,
|
|
generate: () => string,
|
|
): AdminTokenDecision {
|
|
const existing = (existingRaw ?? "").trim();
|
|
if (existing) return { token: existing, reused: true };
|
|
return { token: generate(), reused: false };
|
|
}
|