preflight key-health probe needs an injected seam (DeployTrainService deps)

Aperta
  • Qualcosa non va?
#783 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Read DeployTrainService and its preflight dependency definitions, then follow preflightPublish to see how it invokes checkPublishKeyHealth. Update the dependency wiring and the test in tests/unit/deploy-train-service.test.ts to inject a fake probe. Done means that test makes no outbound requests, no suite module-mocks the probe, and production preflight still uses the real check.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

ready-for-agent

Context

#771 added checkPublishKeyHealth to the publish preflight: before the build train runs, the signing key is probed on-chain (getAccessKey against the registry namespace account) so a rotated or exhausted key surfaces as a named preflight error instead of a silent UNKNOWN_TRANSACTION broadcast.

The probe constructs its own Near client (near-signer.ts) and reaches the real registry RPC from inside runPublishTrain — outside every injected seam the train otherwise routes through (RegistryStore, SignerService, fetchConfig).

The breakage it causes

tests/unit/deploy-train-service.test.ts > routes registry reads and signing through the injected tags exercises exactly that train path, so it inherits the probe's real network:

  • CI: the hermetic-test guard blocks the outbound fetch → the test times out at 15s (run 41781431180, Framework tests).
  • Local: no guard → a real mainnet RPC answers ed25519: is not a publish key (the fixture's key is empty) → PublishTrainError kind preflight.

Either way the test's actual subject — "registry reads and signing route through the injected layers" — never gets exercised hermetically.

Short-term (already shipped in #772, commit 1c75ba61)

The test stubs the module function:

vi.mock("../../src/services/auth/near-signer", () => ({
  ...actual,
  checkPublishKeyHealth: vi.fn(async () => ({ ok: true })),
}));

That makes the suite green but leaves the probe as a module-level side door: any future train test that forgets this mock inherits a real RPC call.

The proper fix

Route the probe through DeployTrainService deps like every other outbound concern:

  1. PreflightDeps (or the train's deps) gains checkPublishKeyHealth — default implementation near-signer's, injectable in tests.
  2. preflightPublish calls it through the deps instead of importing the function directly.
  3. deploy-train-service.test.ts drops the near-signer module mock for the probe and injects a fake through the layer instead (keep the mock only for resolveSigningStrategy if still needed).
  4. The smoke/custody/relay paths that call the real preflight keep the real implementation (no behavior change anywhere in production).

Acceptance

  • deploy-train-service.test.ts runs with zero outbound network (the hermetic guard stays silent for that file).
  • No module-level vi.mock of near-signer's checkPublishKeyHealth anywhere in the suite.
  • Production behavior unchanged: the probe still runs pre-train on real deploys, still soft-fails on an unreachable RPC.

References

  • Introduced by #771 (preflight publish-key verification).
  • Surfaced by #772 (the relayer bring-up PR whose CI first ran the test hermetically).
  • The hermetic-test guard convention: stub the fetch seam / inject the fetch parameter (see the guard's own error message).
Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
9h 58m
PR unite (30g)
212

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NEARBuilders/everything-dev

Tutte le issue di NEARBuilders/everything-dev

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.