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

Abierto
  • ¿Algo no está bien?
#783 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
TypeScript
Estrellas
5
Forks
4
Merge medio
9 h 33 min
PR fusionados (30 d)
213

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NEARBuilders/everything-dev

Todos los issues de NEARBuilders/everything-dev

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.