@marinoscar/platform-api 0.0.0-stage → 0.1.0-next.4

package/dist/nodes/nodes.service.js

@@ -0,0 +1,1017 @@
+"use strict";
+// =============================================================================
+// The node control plane (issue #268, epic #254)
+// =============================================================================
+//
+// THE ONE CONSTRAINT THAT SHAPES EVERY DECISION IN THIS FILE: a worker node
+// has no database access and no storage credentials. Every fact it needs
+// arrives in an HTTP response, and every fact it produces is validated here
+// before anything is trusted. It is authenticated (a `nod_` credential
+// resolves to its owning user) but it is not trusted the way an in-process
+// caller is: it runs unattended on a machine this deployment may not own, its
+// configuration is editable by whoever holds that machine, and it may be
+// running an older build than the server it is talking to.
+//
+// This service is therefore where the queue gains a SECOND EXECUTOR — and the
+// whole point of the design is that the second executor reuses the first
+// one's machinery rather than acquiring its own.
+//
+// -----------------------------------------------------------------------------
+// WHAT THIS SERVICE DELIBERATELY DOES NOT CONTAIN
+// -----------------------------------------------------------------------------
+//
+// REJECTED: a claim query of its own. `JobClaimService.claim` already carries
+// `nodeId` and `executor` as parameters precisely so both claimers share ONE
+// `UPDATE … FOR UPDATE SKIP LOCKED … RETURNING` statement. A node-flavoured
+// copy would start identical and diverge on the first fix applied to one
+// side, and the property that would break is the one nothing tests by
+// accident: two claimers never receiving the same row. The in-process worker
+// and this service pass different arguments to the same statement, and that
+// is the entire difference between them.
+//
+// REJECTED: a terminal update of its own. `JobTerminalService` is the single
+// chokepoint that decides what happens to a row that stopped running — retry,
+// defer, fail — and its header spells out what drifts when two executors each
+// write their own: whether a 429 charges an attempt, whether the settled
+// event fires, what the backoff is. A node reports a CONCLUSION as flags
+// (`rateLimited`, `retryAfterMs`) because an exception cannot cross HTTP, and
+// `completeFailed` gives those flags the identical treatment it gives a
+// thrown `RateLimitError`. So this service classifies nothing.
+//
+// REJECTED: trusting the node's `willRetry`. A node that has just read a
+// provider's response often does know whether the work is worth retrying, and
+// it may say so — but the server's attempt budget decides. A node that could
+// dictate its own retries could retry itself past a budget that exists
+// precisely to bound a job nobody is watching, and the crash-loop that budget
+// prevents would come back on hardware the operator cannot see. The flag is
+// accepted, recorded in the API contract as advisory, and never read.
+//
+// REJECTED: per-job provider-credential brokering, and a model manifest.
+// The application this design was extracted from hands a node short-lived
+// provider credentials per job, and publishes a manifest of model versions
+// the fleet must agree on. Both exist for ML compute this template does not
+// have; porting them would ship an unused secret-distribution path — the most
+// expensive kind of code to carry unused. See docs/specs/worker-nodes.md.
+//
+// -----------------------------------------------------------------------------
+// TWO GUARDS, AND THEY ARE AUTHORITATIVE RATHER THAN DECORATIVE
+// -----------------------------------------------------------------------------
+//
+// `assertOwnership` and `assertJobHeldByNode` are not "checks the controller
+// does first"; they are the only reason the routes below are safe, and every
+// route that touches a node or a job goes through one of them. Both return
+// the row they verified, so no caller needs a second fetch and no caller can
+// accidentally act on a DIFFERENT row than the one that was checked.
+//
+// `assertOwnership` answers 404 for a node that does not exist and 403 for
+// one that belongs to somebody else. That deliberately DIFFERS from
+// `NodeCredentialService.revokeCredential` next door, which folds ownership
+// into the lookup so "not yours" and "does not exist" are indistinguishable —
+// and the difference is worth stating because the reasoning is not the same
+// on both sides. A credential ID is a secret-adjacent handle: distinguishing
+// the two would let a caller enumerate other users' credential IDs, and there
+// is no operational cost to hiding it, because nobody ever legitimately holds
+// a credential ID they do not own.
+//
+// REJECTED for nodes: 404-for-another-user's-node. A node id is not secret —
+// it is printed in logs, embedded in a worker's config file, and passed
+// around by operators — and a node OPERATOR legitimately holds ids they do
+// not own (a colleague's node in the same deployment, a node registered
+// before an ownership change). The realistic failure here is not enumeration,
+// it is misconfiguration: a `nod_` credential paired with the wrong node id
+// in a config file. `404` tells that operator "this node does not exist",
+// which is false and sends them to re-register — leaking a duplicate row and
+// leaving the real node's jobs stranded. `403` tells them the truth: the node
+// exists and this credential is not the one that owns it. A boundary that
+// lies produces worse operational outcomes than one that says no.
+//
+// `assertJobHeldByNode` is the more important of the two. It is reused by every
+// route that speaks for a held job — `renew`, `result` and `failure` here,
+// `download-url` and `upload-url` in `node-data-plane.service.ts`, and `secret`
+// in `node-secret-broker.service.ts` — and it demands FOUR things: the job is
+// claimed by THIS node, it is `running`, it has a lease, and that lease has
+// not expired — plus a FIFTH the caller opts into by quoting the claim token
+// it was handed (#364): that the row is still the same CLAIM, not merely the
+// same node. `claimedByNodeId` tells one node from another and not one node
+// from itself, so without the token a node's stalled, reaped, re-claimed
+// worker slot can renew — or settle — the run its own later slot is executing,
+// be signed a PUT for the output key that run is writing, or be handed that
+// run's database credential. The token is optional on the wire so an
+// un-upgraded node keeps working unchanged; see the method's own doc comment
+// for both halves, and `dto/claim-token.field.ts` for what each of the six
+// routes stands to lose without it.
+//
+// ⚠ THE LEASE CHECK IS WHAT MAKES A LATE SUBMISSION HARMLESS. Consider the
+// ordinary sequence: a node's machine sleeps, its lease expires, the reaper
+// (#263) requeues the job, another executor claims it and starts running it —
+// and then the original node wakes up and posts the result it computed twenty
+// minutes ago. Without the lease check that result is persisted over a newer
+// run: `persistNodeResult` writes stale output, `completeSucceeded` marks a
+// row terminal that another executor is still actively working on, and that
+// executor's own terminal write lands afterwards on a job it no longer owns.
+// The observable damage is a permanently wrong stored result and a duplicated
+// side effect, with nothing in any log tying the two together.
+//
+// REJECTED: answering a late submission with 400. The distinction is not
+// pedantry — it is the instruction the node acts on. `400` means "your
+// request was malformed", and the reasonable client response is to fix and
+// resend; a node that resends will be refused forever, and a node written to
+// treat 4xx as retriable will hammer the endpoint. `409 Conflict` means "the
+// server's state moved on", and the correct node behaviour is to DROP THE
+// WORK: the job is not its problem any more, somebody else owns it. That is
+// the whole message, and only one status code carries it.
+// =============================================================================
+var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+};
+var __metadata = (this && this.__metadata) || function (k, v) {
+    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
+};
+var __param = (this && this.__param) || function (paramIndex, decorator) {
+    return function (target, key) { decorator(target, key, paramIndex); }
+};
+var NodesService_1;
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.NodesService = void 0;
+const common_1 = require("@nestjs/common");
+const config_1 = require("@nestjs/config");
+const index_1 = require("../jobs/index");
+const index_2 = require("../core/index");
+const zod_1 = require("zod");
+const index_3 = require("../jobs/index");
+const index_4 = require("../jobs/index");
+const index_5 = require("../jobs/index");
+const index_6 = require("../jobs/index");
+const index_7 = require("../jobs/index");
+const index_8 = require("../jobs/index");
+const index_9 = require("../jobs/index");
+const index_10 = require("../jobs/index");
+const node_settlement_ledger_1 = require("./node-settlement-ledger");
+/**
+ * How recently a node must have heartbeated for a re-register to be WORTH
+ * MENTIONING in the log.
+ *
+ * It is a warning threshold and nothing else — no request is refused by it.
+ * See `register` for why last-writer-wins is the policy, and why this number
+ * being wrong costs a log line rather than an outage.
+ */
+const FRESH_HEARTBEAT_WARN_MS = 60_000;
+/**
+ * Whether a thrown value is Postgres's unique-violation, as Prisma reports it.
+ *
+ * DUCK-TYPED ON `code` RATHER THAN `instanceof PrismaClientKnownRequestError`.
+ * `instanceof` across a re-exported generated client is a classic
+ * false-negative — two copies of `@prisma/client` in a dependency tree, a
+ * mocked module in a test, a driver adapter that wraps the error — and the
+ * cost of a false negative here is not a nicer error message: it is
+ * `register` giving up on a race it knows how to recover from, and a restarted
+ * container failing to reattach. The string `'P2002'` is Prisma's documented,
+ * stable error code.
+ */
+function isUniqueViolation(error) {
+    return (typeof error === 'object' &&
+        error !== null &&
+        error.code === 'P2002');
+}
+/** Zod's issue list, flattened to something a node can print. */
+function describeValidationError(error) {
+    const issues = error.issues;
+    if (Array.isArray(issues)) {
+        return issues.map((issue) => ({
+            path: Array.isArray(issue.path) ? issue.path.join('.') : '',
+            message: issue.message ?? 'Invalid value',
+        }));
+    }
+    return error instanceof Error ? error.message : String(error);
+}
+/**
+ * The node control plane: register, heartbeat, claim, renew, result and failure, each gated by node ownership and the held claim.
+ *
+ * @stability experimental
+ */
+let NodesService = NodesService_1 = class NodesService {
+    prisma;
+    config;
+    claims;
+    terminal;
+    leases;
+    registry;
+    offload;
+    settlements;
+    logger = new common_1.Logger(NodesService_1.name);
+    constructor(prisma, config, claims, terminal, 
+    // The renewal half of the claim (#347), shared verbatim with the
+    // in-process worker. See `renewLease` for why the guard it carries must
+    // not be written twice.
+    leases, registry, 
+    // WHAT A NODE MAY CLAIM HERE, RIGHT NOW (#349, #352). It replaced a
+    // `NodeLifecycleService` injected for one settings field, because the
+    // question grew two more gates and — critically — acquired a SECOND
+    // READER: `JobWorker`'s `system` mode consumes the complement of this
+    // exact set. See `nodeEligibleTypes` below, and the service's own header
+    // for the partition argument.
+    offload, settlements = new node_settlement_ledger_1.NodeSettlementLedger()) {
+        this.prisma = prisma;
+        this.config = config;
+        this.claims = claims;
+        this.terminal = terminal;
+        this.leases = leases;
+        this.registry = registry;
+        this.offload = offload;
+        this.settlements = settlements;
+    }
+    // ===========================================================================
+    // Registration
+    // ===========================================================================
+    /**
+     * Registers a node, or REATTACHES to the one this owner already has under
+     * this name.
+     *
+     * ⚠ IDEMPOTENT ON `(createdById, name)`, and that is the entire reason the
+     * composite unique index exists. Without it, every restart of a worker
+     * container — a deploy, an OOM kill, a host reboot, a `docker compose up`
+     * after an edit — leaks a new `worker_nodes` row. Within a week the fleet
+     * page is a list of ghosts, `GET /nodes` is unreadable, and the operator
+     * cannot tell which row is the machine currently doing work. Reattaching
+     * makes a restart a non-event: same row, same id, refreshed facts.
+     *
+     * FIND, THEN CREATE, THEN RECOVER FROM P2002. The find covers the ordinary
+     * restart. The `P2002` branch covers the case the find cannot: two API
+     * replicas (or two node processes racing on startup) both find nothing and
+     * both insert, and exactly one of them loses. Losing that race is not an
+     * error — the row it wanted now exists — so it re-reads and reattaches to
+     * it. REJECTED: a `$transaction` with `SERIALIZABLE` isolation to make the
+     * race impossible. It would serialise an endpoint every node in the fleet
+     * calls at startup in order to avoid an outcome that is already correct
+     * when it happens; the unique index is the guarantee, and this is just
+     * reading it.
+     *
+     * A FRESH HEARTBEAT WARNS BUT PROCEEDS. If the existing row heartbeated
+     * seconds ago, two processes may genuinely be claiming the same node
+     * identity — but the overwhelmingly common cause is a container that was
+     * killed and recreated before its last heartbeat aged out, which is exactly
+     * the case this endpoint exists to handle gracefully. Refusing would turn
+     * the NORMAL restart into a hard failure at startup, on a machine with
+     * nobody watching, and the operator's only recovery would be to wait or to
+     * invent a new name (leaking the row we just avoided leaking). So the
+     * documented policy is LAST-WRITER-WINS, with a log line naming both hosts
+     * so a genuine duplicate is visible to whoever goes looking.
+     */
+    async register(userId, dto) {
+        const existing = await this.findByName(userId, dto.name);
+        if (existing) {
+            return { node: await this.reattach(existing, dto), reattached: true };
+        }
+        try {
+            const node = await this.prisma.workerNode.create({
+                data: {
+                    name: dto.name,
+                    hostname: dto.hostname,
+                    platform: dto.platform,
+                    cliVersion: dto.cliVersion,
+                    eligibleTypes: dto.eligibleTypes,
+                    concurrency: dto.concurrency,
+                    status: index_1.NodeStatus.online,
+                    createdById: userId,
+                    ...(dto.capabilities === undefined
+                        ? {}
+                        : { capabilities: dto.capabilities }),
+                },
+            });
+            this.logger.log(`Registered worker node ${node.id} ("${node.name}" on ${node.hostname}, ` +
+                `concurrency ${node.concurrency}, types [${node.eligibleTypes.join(', ')}])`);
+            return { node, reattached: false };
+        }
+        catch (error) {
+            if (!isUniqueViolation(error)) {
+                throw error;
+            }
+            // Somebody else won the insert between our find and our create. The row
+            // we wanted exists; reattach to it instead of failing a startup.
+            const raced = await this.findByName(userId, dto.name);
+            if (!raced) {
+                // A P2002 with no row behind it means the constraint that fired was
+                // not the one we think it was. Re-throw rather than inventing a
+                // recovery for a conflict we cannot see.
+                throw error;
+            }
+            this.logger.warn(`Concurrent registration of node "${dto.name}" for user ${userId}; ` +
+                `reattaching to the row that won (${raced.id}).`);
+            return { node: await this.reattach(raced, dto), reattached: true };
+        }
+    }
+    /**
+     * Refreshes an existing row from a fresh registration.
+     *
+     * ⚠ `disabled` SURVIVES A REATTACH. Everything else about the row is
+     * overwritten by what the node just reported, and the status goes back to
+     * `online` — except when an operator has disabled this node, in which case
+     * the status is left exactly as it is. `disabled` is the kill switch: it is
+     * how an operator says "this machine must not take work", and a node that
+     * could clear it by restarting would make the switch defeatable with
+     * `docker restart` — by the very process being switched off. The claim
+     * endpoint refuses a disabled node, so preserving the status here is what
+     * makes that refusal permanent rather than one restart long.
+     *
+     * `draining` is NOT preserved, and the asymmetry is deliberate: draining
+     * means "finish what you are holding and take nothing new", which is a
+     * statement about the process that WAS running. A re-register is a new
+     * process that holds nothing, so there is nothing left to drain and keeping
+     * the flag would silently produce a node that heartbeats forever and never
+     * claims.
+     */
+    async reattach(existing, dto) {
+        const lastHeartbeat = existing.lastHeartbeatAt;
+        if (lastHeartbeat && Date.now() - lastHeartbeat.getTime() < FRESH_HEARTBEAT_WARN_MS) {
+            this.logger.warn(`Node "${existing.name}" (${existing.id}) re-registered from ${dto.hostname} while ` +
+                `its previous registration on ${existing.hostname} was still heartbeating ` +
+                `(${lastHeartbeat.toISOString()}). Proceeding: last writer wins. If this repeats, ` +
+                `two processes are sharing one node name.`);
+        }
+        return this.prisma.workerNode.update({
+            where: { id: existing.id },
+            data: {
+                hostname: dto.hostname,
+                platform: dto.platform,
+                cliVersion: dto.cliVersion,
+                eligibleTypes: dto.eligibleTypes,
+                concurrency: dto.concurrency,
+                ...(existing.status === index_1.NodeStatus.disabled ? {} : { status: index_1.NodeStatus.online }),
+                ...(dto.capabilities === undefined
+                    ? {}
+                    : { capabilities: dto.capabilities }),
+            },
+        });
+    }
+    /**
+     * Marks a node offline on a graceful shutdown.
+     *
+     * ⚠ IT DOES NOT TOUCH THE JOBS THE NODE IS HOLDING, and that is the whole
+     * decision in this method. Requeueing them here is the obvious "helpful"
+     * addition and it is wrong: `deregister` is an HTTP call a node makes while
+     * shutting down, and nothing proves the work has actually stopped — a
+     * process handling SIGTERM may still be mid-write, and a node whose
+     * shutdown is interrupted may not stop at all. Requeueing on the node's
+     * say-so would hand a still-running job to a second executor and duplicate
+     * whatever it does.
+     *
+     * The component that is allowed to decide a claim is dead is the lease
+     * reaper (#263), and it decides it the only way that is safe: by the lease
+     * having expired. A deregistered node's jobs therefore come back one lease
+     * later, which is exactly what happens when a node crashes instead of
+     * shutting down politely — one path, tested once, with no way for a
+     * cooperative node to reach a state an uncooperative one cannot.
+     */
+    async deregister(userId, nodeId) {
+        const node = await this.assertOwnership(userId, nodeId);
+        this.logger.log(`Node ${node.id} ("${node.name}") deregistered`);
+        return this.prisma.workerNode.update({
+            where: { id: node.id },
+            data: { status: index_1.NodeStatus.offline },
+        });
+    }
+    /**
+     * Records liveness, and optionally refreshes what the node reports about
+     * itself.
+     *
+     * ⚠ A HEARTBEAT CANNOT CLEAR `disabled` OR `draining`. Those two are
+     * OPERATOR state (see `WorkerNode.status` in `schema.prisma`): a human or
+     * #270's lifecycle cron decided them, and they are decisions ABOUT the node
+     * rather than facts reported BY it. A node whose heartbeat could set
+     * `online` would walk out of its own kill switch on the next tick — five
+     * seconds after an operator disabled it, with the operator watching the
+     * fleet page show `online` and having no idea why. So the reported status
+     * is applied only when the current status is one the node owns.
+     *
+     * `concurrency` IS applied, and applying it here is the entire mechanism
+     * behind "a runtime `set-concurrency` takes effect on the next claim": the
+     * claim endpoint re-reads this row rather than caching anything, so a
+     * heartbeat is all it takes.
+     *
+     * `vitals` (#604), when present, replaces `lastVitals` wholesale and stamps
+     * `lastVitalsAt` with the same server clock as `lastHeartbeatAt`, in this
+     * one update. The row written is ALWAYS the path id after `assertOwnership`
+     * — nothing in the body can name a node, so a node cannot report vitals
+     * onto another node's row.
+     */
+    async heartbeat(userId, nodeId, dto) {
+        const node = await this.assertOwnership(userId, nodeId);
+        const operatorOwned = node.status === index_1.NodeStatus.disabled || node.status === index_1.NodeStatus.draining;
+        if (dto.status && operatorOwned) {
+            this.logger.debug(`Ignoring node ${node.id}'s self-reported status "${dto.status}": the row is ` +
+                `"${node.status}", which only an operator may change.`);
+        }
+        const now = new Date();
+        return this.prisma.workerNode.update({
+            where: { id: node.id },
+            data: {
+                lastHeartbeatAt: now,
+                ...(dto.status && !operatorOwned ? { status: dto.status } : {}),
+                ...(dto.concurrency === undefined ? {} : { concurrency: dto.concurrency }),
+                ...(dto.capabilities === undefined
+                    ? {}
+                    : { capabilities: dto.capabilities }),
+                // The snapshot and its timestamp move together or not at all: a
+                // heartbeat without `vitals` (every pre-#604 node) leaves the last
+                // snapshot and its age intact rather than blanking the fleet page.
+                ...(dto.vitals === undefined
+                    ? {}
+                    : { lastVitals: dto.vitals, lastVitalsAt: now }),
+            },
+        });
+    }
+    // ===========================================================================
+    // Reads
+    // ===========================================================================
+    /** Every node this user registered. */
+    async listNodes(userId) {
+        return this.prisma.workerNode.findMany({
+            where: { createdById: userId },
+            orderBy: { name: 'asc' },
+        });
+    }
+    /** One node, if it is this user's. */
+    async getNode(userId, nodeId) {
+        return this.assertOwnership(userId, nodeId);
+    }
+    // ===========================================================================
+    // Claiming
+    // ===========================================================================
+    /**
+     * Takes up to the node's remaining capacity in runnable jobs, for the types
+     * the node can actually run.
+     *
+     * THREE FILTERS, APPLIED IN THIS ORDER, and each one exists because of a
+     * different way a fleet goes wrong:
+     *
+     *   1. WHAT THE NODE ASKED FOR, intersected with WHAT IT REGISTERED. A node
+     *      can only ever NARROW, never widen: the request says which of its own
+     *      types it currently has slots for, and anything it did not declare is
+     *      dropped rather than honoured. Otherwise a node's claim request — the
+     *      one input a compromised or misconfigured worker fully controls —
+     *      would be enough to pull job types it was never approved for, and
+     *      registration would stop meaning anything.
+     *   2. WHAT A NODE CAN ACTUALLY RUN AT ALL: the types whose handler carries
+     *      both `nodeResultSchema` and `persistNodeResult`. A node that claims a
+     *      server-only type will compute something this server cannot store —
+     *      its result post is refused as "not node-persistable", the row sits
+     *      until its lease expires, the reaper requeues it, and the node claims
+     *      it again. That is an infinite loop that burns an attempt per lap and
+     *      looks, from the queue's side, like a job that keeps failing for no
+     *      reason. Dropping the type here (with a warning naming it) makes the
+     *      misconfiguration visible instead of expensive. REJECTED: letting the
+     *      claim through and discovering it at result time, which is the same
+     *      information one full lease later.
+     *   3. THE CONCURRENCY CLAMP, read LIVE off the row. Never the value
+     *      captured at registration, so `set-concurrency` through a heartbeat
+     *      takes effect on the very next claim, and never the node's requested
+     *      limit if it is larger — a node asking for more than it declared is
+     *      describing slots it does not have.
+     *
+     * STATUS GATES BEFORE ANY OF THAT. `disabled` is 403: an operator has
+     * switched this node off, the answer will not change by polling, and the
+     * node should stop asking. `draining` is an EMPTY LIST rather than an
+     * error, because draining is a normal state with a normal instruction —
+     * "finish what you hold, take nothing new" — and a node that must keep
+     * heartbeating and keep renewing leases while it drains must not be taught
+     * that this endpoint is failing.
+     *
+     * `lastHeartbeatAt` IS NOT STAMPED HERE. Liveness has exactly one writer
+     * (`heartbeat`), so "when did we last hear from this node" stays a question
+     * about a column one route moves. A claim that also stamped it would let a
+     * node that polls but never heartbeats look healthy on the fleet page
+     * through a path that reports nothing about its health.
+     */
+    async claimJobs(userId, nodeId, dto) {
+        const node = await this.assertOwnership(userId, nodeId);
+        if (node.status === index_1.NodeStatus.disabled) {
+            throw new common_1.ForbiddenException({
+                message: `Node ${node.id} is disabled and may not claim jobs. An operator disabled it; ` +
+                    `re-registering will not clear that.`,
+                details: { nodeId: node.id, status: node.status },
+            });
+        }
+        if (node.status === index_1.NodeStatus.draining) {
+            this.logger.debug(`Node ${node.id} is draining; returning no jobs.`);
+            return [];
+        }
+        const declared = new Set(node.eligibleTypes);
+        const requested = dto.types?.length ? dto.types : node.eligibleTypes;
+        const withinRegistration = requested.filter((type) => declared.has(type));
+        const undeclared = requested.filter((type) => !declared.has(type));
+        if (undeclared.length > 0) {
+            this.logger.warn(`Node ${node.id} asked for type(s) it never registered: ` +
+                `[${undeclared.join(', ')}]. Dropped — a node may narrow its registration, ` +
+                `never widen it.`);
+        }
+        const nodeEligible = new Set(await this.nodeEligibleTypes());
+        const eligibleTypes = withinRegistration.filter((type) => nodeEligible.has(type));
+        const serverOnly = withinRegistration.filter((type) => !nodeEligible.has(type));
+        if (serverOnly.length > 0) {
+            this.logger.warn(`Node ${node.id} declared type(s) no node can run: [${serverOnly.join(', ')}]. ` +
+                `Their handlers carry no nodeResultSchema/persistNodeResult pair, so this server ` +
+                `could not store a result for them. Dropped from the claim.`);
+        }
+        const limit = Math.max(0, Math.min(dto.limit ?? node.concurrency, node.concurrency));
+        return this.claims.claim({
+            nodeId: node.id,
+            executor: 'node',
+            eligibleTypes,
+            limit,
+            // Derived on the server, identically to the in-process worker's — see
+            // `resolveJobLeaseMs`, and the file header on why a node does not get
+            // to choose its own lease.
+            //
+            // ONE PER TYPE, from the SAME intersected list passed as
+            // `eligibleTypes` just above (#346). This is the claim that made
+            // per-row leases necessary at all: a node takes up to its concurrency
+            // ACROSS SEVERAL TYPES in one statement, so with per-type runtime
+            // ceilings those rows do not share a lease. Built by the same
+            // `buildClaimLeases` the in-process worker calls, so the fleet and the
+            // server derive the identical lease for the identical type — the lease
+            // is the reaper's contract, not a claimer's private detail.
+            leases: (0, index_4.buildClaimLeases)(this.config, this.registry, eligibleTypes),
+        });
+    }
+    /**
+     * How often a node should renew the lease on a job of `type`, in
+     * milliseconds — the server's answer, derived from the very lease the claim
+     * granted.
+     *
+     * ⚠ THE SERVER DERIVES THIS, NOT THE NODE, for the same reason the server
+     * derives the lease itself (see `claimJobs`): the renewal cadence and the
+     * lease are one arithmetic relationship, and letting the two ends compute
+     * their halves independently is how a node ends up renewing every 30 seconds
+     * against a lease it was never told about — or, worse, less often than the
+     * lease it holds, losing jobs it is actively running while doing everything
+     * right. `resolveRenewIntervalMs` is the one derivation, and it is a third
+     * of the lease so two consecutive missed renewals still cost nothing.
+     *
+     * The practical case that made this worth a wire field (#347): a type
+     * declaring a six-hour `maxRuntimeMs` takes a six-hour lease, and the CLI's
+     * shipped `DEFAULT_LEASE_RENEW_MS` of 30 seconds would spend 720 round trips
+     * on it to no purpose whatsoever.
+     *
+     * ADDITIVE AND BACKWARD-COMPATIBLE on both ends: a node that ignores the
+     * field keeps its own cadence and stays correct, and this method is total —
+     * an unregistered type falls back through `resolveJobProfile`/
+     * `resolveJobLeaseMs` to the deployment-wide lease exactly as the claim
+     * would have.
+     */
+    renewIntervalMsFor(type) {
+        return (0, index_4.resolveRenewIntervalMs)((0, index_10.resolveJobLeaseMs)(this.config, (0, index_4.resolveJobProfile)(this.registry.get(type))));
+    }
+    /**
+     * Extends the lease on a job this node is still legitimately holding.
+     *
+     * ⚠ THE WRITE RE-ASSERTS THE GUARD IN ITS OWN `WHERE` CLAUSE rather than
+     * trusting the check that just passed. Between `assertJobHeldByNode`
+     * reading the row and this statement running, the reaper can requeue the
+     * job and another executor can claim it — the window is small and it is
+     * real, and a renewal that landed inside it would extend a lease belonging
+     * to somebody else, keeping the reaper away from a job the ORIGINAL node is
+     * no longer running. `updateMany` with the ownership conditions makes the
+     * check and the write the same statement; a zero count means the state
+     * moved, which is a 409 exactly as a stale read would have been.
+     *
+     * ⚠ THAT GUARD NOW LIVES IN `JobLeaseService.heldLeaseWhere` (#347), NOT
+     * HERE, and moving it there was the point of that issue rather than tidying.
+     * The in-process worker renews too now, and "a lease that has already
+     * expired may not be renewed, because another executor may own the row" is a
+     * claim about the queue's invariants, not about this endpoint. Written twice
+     * it drifts exactly once — somebody relaxes the expiry predicate on one side
+     * to stop a flaky node losing jobs, and from then on that side can resurrect
+     * a lease on a row the reaper has already given away. This is the same
+     * argument `resolveJobLeaseMs` makes about deriving the lease: one function,
+     * one rule, both executors.
+     *
+     * The 409 stays here, because it is the only part that is about HTTP: the
+     * shared service answers `false`, and only a caller who has a remote client
+     * waiting turns that into a status code.
+     */
+    async renewLease(userId, nodeId, jobId, claimToken) {
+        const job = await this.assertJobHeldByNode(userId, nodeId, jobId, claimToken);
+        // The renewal grants the SAME lease the claim did, which means resolving
+        // it from the same profile: a renewal computed from the deployment-wide
+        // timeout would hand a six-hour type a ten-minute extension and have the
+        // reaper take the job away from a node that is renewing on schedule.
+        const leaseExpiresAt = new Date(Date.now() + (0, index_10.resolveJobLeaseMs)(this.config, (0, index_4.resolveJobProfile)(this.registry.get(job.type))));
+        // `renewUntil`, not `renew`: the instant written to the row has to be the
+        // instant reported in the response, or the node schedules its next
+        // renewal against a deadline the reaper does not read.
+        //
+        // `claimToken` IS FORWARDED WHEN — AND ONLY WHEN — THE NODE SENT ONE
+        // (#364). This used to be omitted on purpose, and the reason was sound
+        // while it held: the token could only have come off the row this statement
+        // matches, so checking it against that same row proved nothing. It now
+        // comes from the NODE, quoted back from its claim response, so it is an
+        // assertion arriving from outside this transaction and checking it is the
+        // whole point. And it has to be checked HERE too, not only in the read
+        // above: `heldLeaseWhere` inside `updateMany` is what closes the window
+        // between that read and this write, in which the reaper can requeue the
+        // row and this node's own second slot can re-claim it.
+        //
+        // `undefined` when the node said nothing, which `heldLeaseWhere` renders
+        // as no token clause at all — pre-#364 behaviour exactly, for a node that
+        // has not been upgraded yet. Note this is `undefined`, never `null`:
+        // `null` would mean "match only a row whose token IS NULL", which is a
+        // different, much narrower statement (see `heldLeaseWhere`).
+        const held = await this.leases.renewUntil(job.id, leaseExpiresAt, { nodeId, claimToken });
+        if (!held) {
+            throw this.notHeldByNode(jobId, nodeId);
+        }
+        return { jobId: job.id, leaseExpiresAt };
+    }
+    // ===========================================================================
+    // Result ingestion
+    // ===========================================================================
+    /**
+     * Accepts a node-computed result, validates it, persists it, and settles
+     * the job.
+     *
+     * THE ORDER OF THE FIVE STEPS BELOW IS THE CONTRACT, and each step is a
+     * different untrusted claim being checked before anything irreversible
+     * happens. Nothing writes until the last two.
+     *
+     * WHY THE SCHEMA IS PARSED BY HAND HERE INSTEAD OF BY THE GLOBAL PIPE.
+     * `nestjs-zod`'s pipe validates against a schema known at decoration time;
+     * WHICH schema applies here is not known until the job row has been read
+     * and its handler resolved, because it is the handler's `nodeResultSchema`.
+     * There is no decorator that can express "the schema belonging to the type
+     * of the row named in the path", so the parse happens where the information
+     * exists — and its failure is converted into the same clean 400 the pipe
+     * would have produced, with the issue list in `details` (the exception
+     * filter rebuilds bodies from a fixed key allowlist, so a custom field has
+     * nowhere else to go).
+     *
+     * ⚠ A `persistNodeResult` THROW BECOMES A JOB FAILURE, NOT AN API ERROR
+     * THE NODE SHOULD RETRY. This is the subtlest decision in the file. Once
+     * the server has begun persisting, it — not the node — owns the row's
+     * lifecycle: the failure is routed through `completeFailed`, so it enters
+     * the ordinary retry machine (backoff, attempt budget, eventual `failed`
+     * with a readable `lastError`) exactly as an in-process handler's throw
+     * would. The node is then told 500, which means "this is ours, not yours".
+     * REJECTED: returning 4xx and letting the node resubmit. The job is no
+     * longer `running` by then — `completeFailed` has already moved it — so
+     * every resubmission would be refused by `assertJobHeldByNode` anyway, and
+     * a node retrying a persist failure would hammer the endpoint while the
+     * server's own retry was already scheduled. REJECTED equally: swallowing
+     * the throw and returning success, which would leave a job marked
+     * `succeeded` with nothing written.
+     *
+     * ⚠ THE ONE EXCEPTION IS A LOST CLAIM (#477). Every terminal write is
+     * guarded by the claim (`heldClaimWhere`), so if the row was reaped or
+     * re-claimed between step 1 and the settle, the settle writes nothing and
+     * answers `claim-lost`. On either path — the normal settle or the
+     * persist-failure one — that becomes the SAME 409 step 1 raises, because it
+     * is the same fact discovered a moment later, and a 500 claiming "settled by
+     * this server" would be false.
+     */
+    async submitResult(userId, nodeId, jobId, dto) {
+        // 1. Is this job this node's to speak for, right now? `dto.claimToken`
+        // narrows that from "this node" to "this CLAIM of this node" when the node
+        // is new enough to quote it (#364) — the difference between refusing a
+        // stale worker slot's result and persisting it over the run a later slot
+        // of the same node is still executing.
+        const job = await this.assertJobHeldByNode(userId, nodeId, jobId, dto.claimToken);
+        // 2. Is the node talking about the job it thinks it is talking about?
+        if (dto.type !== job.type) {
+            throw new common_1.BadRequestException({
+                message: `This result declares type "${dto.type}" but job ${job.id} is of type ` +
+                    `"${job.type}". Nothing was persisted.`,
+                details: { jobId: job.id, expectedType: job.type, receivedType: dto.type },
+            });
+        }
+        // 3. Can this server store a node-computed result for this type at all?
+        const handler = this.registry.get(job.type);
+        const schema = handler?.nodeResultSchema;
+        const persist = handler?.persistNodeResult;
+        if (!handler || !schema || typeof persist !== 'function') {
+            throw new common_1.BadRequestException({
+                message: `Job type "${job.type}" is not node-persistable: its handler carries no ` +
+                    `nodeResultSchema/persistNodeResult pair, so this server cannot store a ` +
+                    `node-computed result for it.`,
+                details: { jobId: job.id, type: job.type },
+            });
+        }
+        // 4. Is the payload the shape that type promised? THE TRUST BOUNDARY.
+        let parsed;
+        try {
+            parsed = schema.parse(dto.result);
+        }
+        catch (error) {
+            throw new common_1.BadRequestException({
+                message: `The result for job ${job.id} failed validation for type "${job.type}".`,
+                details: { jobId: job.id, type: job.type, issues: describeValidationError(error) },
+            });
+        }
+        // 5. Write it down — and if that throws, the job failed, not the request.
+        try {
+            await persist.call(handler, job, parsed);
+        }
+        catch (error) {
+            const outcome = await this.terminal.completeFailed(job, error);
+            // The claim moved between `assertJobHeldByNode` and the settle (#477):
+            // nothing was written, so "settled by this server" would be false.
+            // Answer the same 409 the read guard would have, had it run a moment
+            // later — the node's instruction (drop the work) is identical.
+            if (outcome === 'claim-lost') {
+                this.logger.warn(`Persisting node ${nodeId}'s result for job ${job.id} (${job.type}) threw, and the ` +
+                    `job was no longer held by that claim when the failure was recorded: ` +
+                    `${error instanceof Error ? error.message : String(error)}`);
+                throw this.notHeldByNode(jobId, nodeId);
+            }
+            // The server settled it, but it was THIS node's run: its spans are
+            // still this node's to relay (#608).
+            this.settlements.record(job.id, nodeId);
+            this.logger.error(`Persisting node ${nodeId}'s result for job ${job.id} (${job.type}) threw; the job ` +
+                `was settled as "${outcome}" through the normal failure path: ` +
+                `${error instanceof Error ? error.message : String(error)}`);
+            throw new common_1.InternalServerErrorException({
+                message: `The result for job ${job.id} could not be persisted. The job has been settled ` +
+                    `by this server; do not resubmit.`,
+                details: { jobId: job.id, outcome, resubmit: false },
+            });
+        }
+        const outcome = await this.terminal.completeSucceeded(job);
+        // ⚠ `persistNodeResult` HAS ALREADY RUN when this fires — the settle was
+        // refused, not the persist. It is the same exposure the read guard always
+        // had between its read and the persist, narrowed rather than introduced:
+        // before #477 the settle would ALSO have overwritten the new claim's row.
+        if (outcome === 'claim-lost') {
+            throw this.notHeldByNode(jobId, nodeId);
+        }
+        // Proven held, and now settled by this node — the span relay's grace (#608).
+        this.settlements.record(job.id, nodeId);
+        return { jobId: job.id, outcome, willRetry: this.willRetry(outcome) };
+    }
+    /**
+     * Records a failure a node reports for a job it is holding.
+     *
+     * A PASS-THROUGH BY DESIGN. The flags go straight into `completeFailed`,
+     * which treats `rateLimited` identically to a `RateLimitError` thrown by an
+     * in-process handler — down to tripping this server's own throttle gate, so
+     * a node's 429 backs off sibling jobs running here too. This service
+     * classifies nothing and decides nothing; see the file header on why both
+     * executors must reach their conclusions through the same code.
+     *
+     * `willRetry` ARRIVES AND IS IGNORED. The response tells the node what the
+     * server actually decided, which is the only version of that answer that
+     * governs anything.
+     */
+    async reportFailure(userId, nodeId, jobId, dto) {
+        // `dto.claimToken` for the same reason `submitResult` passes it: a failure
+        // is terminal too, and an old slot's "boom" must not charge an attempt
+        // against — or settle — the run a newer claim is executing fine (#364).
+        const job = await this.assertJobHeldByNode(userId, nodeId, jobId, dto.claimToken);
+        const outcome = await this.terminal.completeFailed(job, new Error(dto.error), {
+            rateLimited: dto.rateLimited,
+            retryAfterMs: dto.retryAfterMs,
+        });
+        // Lost between the guard's read and the settle's write (#477): the same
+        // 409 the guard gives a stale read — nothing was charged or written.
+        if (outcome === 'claim-lost') {
+            throw this.notHeldByNode(jobId, nodeId);
+        }
+        // Proven held, and now settled by this node — the span relay's grace (#608).
+        this.settlements.record(job.id, nodeId);
+        this.logger.log(`Node ${nodeId} reported job ${job.id} (${job.type}) failed; settled as "${outcome}"` +
+            `${dto.rateLimited ? ' (node reported a provider rate limit)' : ''}`);
+        return { jobId: job.id, outcome, willRetry: this.willRetry(outcome) };
+    }
+    // ===========================================================================
+    // The published contract
+    // ===========================================================================
+    /**
+     * Every job type a node could run, each with the JSON Schema its results
+     * must satisfy.
+     *
+     * THIS IS THE ONE PLACE THE RESULT CONTRACT CROSSES A PROCESS BOUNDARY, and
+     * it does so as DATA rather than as a shared build artefact. A client — the
+     * CLI is the first — validates a result before posting it, against the
+     * schema this server will actually enforce in `submitResult`, generated from
+     * the very same Zod object. There is no second definition to drift, no
+     * package to publish, and no way for a client on an older release to
+     * validate against a schema this server stopped using.
+     *
+     * REJECTED: a shared `packages/job-contracts` workspace exporting the Zod
+     * schemas to every app. `packages/shared/index.js` already documents, at
+     * length, why a compiled workspace package does not work in this
+     * repository: `apps/api` builds with `rootDir: ./src`, so importing
+     * TypeScript source from outside it widens the root and tsc starts emitting
+     * `dist/src/main.js`, which no longer matches `start:prod`'s
+     * `node dist/main` — a green build and a broken container. Its Jest config has no
+     * `moduleNameMapper` and the default `transformIgnorePatterns`, so a
+     * workspace symlink resolving to `.ts` would be untransformed and every API
+     * suite would die at import time. And CI runs `npm ci` straight into
+     * typecheck, so a package needing compilation would have to add a build step
+     * to several jobs. `packages/shared` escapes all of that by shipping
+     * committed `.js` plus a hand-written `.d.ts` — which is fine for a string
+     * constant and useless for a Zod schema, whose entire value is the runtime
+     * object.
+     *
+     * ⚠ `resultSchema` IS `null` RATHER THAN `{}` WHEN CONVERSION FAILS.
+     * `z.toJSONSchema` throws on a schema with no JSON Schema representation (a
+     * `z.custom()`, a `z.date()`, a transform), and the tempting rescue is to
+     * publish an empty schema. That would be a LIE in the most expensive
+     * direction: `{}` in JSON Schema means "anything is valid", so a client
+     * would confidently validate garbage and be refused by the server it just
+     * agreed with. `null` says "this one cannot be published — submit it and
+     * let the server answer", which is true and actionable. The type is still
+     * listed, because it is still claimable.
+     */
+    async listNodeEligibleJobTypes() {
+        const types = await this.nodeEligibleTypes();
+        return types.map((type) => ({
+            type,
+            label: (0, index_8.jobTypeLabel)(type),
+            resultSchema: this.toPublishableSchema(type),
+        }));
+    }
+    /**
+     * `handler.nodeResultSchema` as JSON Schema, or `null` if it cannot be one.
+     *
+     * `io: 'input'` because what is being published is what a client must SEND.
+     * The distinction is invisible for a plain object schema and real the moment
+     * a schema grows a default or a coercion, where the input shape and the
+     * parsed output shape stop agreeing — and publishing the output shape would
+     * tell a client to send a field the server actually supplies for it.
+     */
+    toPublishableSchema(type) {
+        const schema = this.registry.get(type)?.nodeResultSchema;
+        if (!schema) {
+            return null;
+        }
+        try {
+            return zod_1.z.toJSONSchema(schema, { io: 'input' });
+        }
+        catch (error) {
+            this.logger.warn(`Job type "${type}" is node-eligible but its nodeResultSchema has no JSON Schema ` +
+                `representation, so clients cannot validate against it before submitting: ` +
+                `${error instanceof Error ? error.message : String(error)}`);
+            return null;
+        }
+    }
+    // ===========================================================================
+    // The two shared guards
+    // ===========================================================================
+    /**
+     * The node exists AND belongs to this caller — 404 for the first, 403 for
+     * the second.
+     *
+     * ONE QUERY, and it RETURNS THE ROW. Both properties are deliberate: a
+     * caller that had to fetch the node again after the check could act on a
+     * different row than the one that was verified, and the second read would
+     * be a second chance to forget the check entirely.
+     *
+     * See the file header for why this deliberately distinguishes "missing"
+     * from "not yours" where `NodeCredentialService` deliberately does not.
+     */
+    async assertOwnership(userId, nodeId) {
+        const node = await this.prisma.workerNode.findUnique({ where: { id: nodeId } });
+        if (!node) {
+            throw new common_1.NotFoundException({
+                message: `Worker node ${nodeId} was not found.`,
+                details: { nodeId },
+            });
+        }
+        if (node.createdById !== userId) {
+            throw new common_1.ForbiddenException({
+                message: `Worker node ${nodeId} belongs to another user. Check that this credential and ` +
+                    `this node id came from the same registration.`,
+                details: { nodeId },
+            });
+        }
+        return node;
+    }
+    /**
+     * The job is claimed by THIS node, is `running`, its lease has not expired,
+     * and — when the caller quotes one — it is still THIS CLAIM of it.
+     * Otherwise 409.
+     *
+     * THE CONDITIONS ARE ONE CONDITION, checked together and reported together.
+     * Splitting them into distinct errors would tell a remote caller which of
+     * "wrong node", "already finished" and "lease expired" applied, which is
+     * information about another executor's progress that a node has no use for
+     * and cannot act on differently — its correct response is the same in all
+     * three cases: drop the work.
+     *
+     * ⚠ `claimToken` JOINS THAT SAME 409 RATHER THAN RAISING ONE OF ITS OWN
+     * (#364), and the argument is the paragraph above, unchanged. "You are the
+     * right node but the wrong claim" is a fact about another slot's progress —
+     * a slot of this very node, which makes it no more actionable — and the
+     * correct response to it is identical: drop the work. A distinct error code
+     * would tempt a client to treat it as recoverable and re-fetch, which is the
+     * one thing it must not do.
+     *
+     * ⚠ OPTIONAL, AND ABSENT MEANS THE PRE-#364 CHECK, EXACTLY. A node running
+     * older CLI code does not know the token exists, so it omits it and is
+     * identified by `claimedByNodeId` alone — no 400, no 409, no warning that
+     * would break a fleet halfway through a rolling upgrade. Such a node stays
+     * self-ambiguous (its own stale slot can still speak for a newer claim) until
+     * it is upgraded; nothing this server can do closes that earlier, since the
+     * only thing that can tell those two slots apart is a value only they hold.
+     * Same additive posture as `renewIntervalMs` in #347.
+     *
+     * See the file header for the late-submission scenario this prevents, and
+     * for why the answer is 409 rather than 400.
+     */
+    async assertJobHeldByNode(userId, nodeId, jobId, claimToken) {
+        // Ownership first: a caller who does not own the node must not learn
+        // anything about the jobs it holds, including whether a job id exists.
+        await this.assertOwnership(userId, nodeId);
+        const job = await this.prisma.job.findUnique({ where: { id: jobId } });
+        if (!job) {
+            throw new common_1.NotFoundException({
+                message: `Job ${jobId} was not found.`,
+                details: { jobId },
+            });
+        }
+        if (job.claimedByNodeId !== nodeId ||
+            job.status !== 'running' ||
+            !job.leaseExpiresAt ||
+            job.leaseExpiresAt <= new Date() ||
+            // `claimToken !== undefined` first, and it is the backward-compatibility
+            // guarantee in one operator: a caller that quotes no token is never
+            // failed by this clause, whatever the row happens to carry.
+            (claimToken !== undefined && job.claimToken !== claimToken)) {
+            throw this.notHeldByNode(jobId, nodeId);
+        }
+        return job;
+    }
+    // ===========================================================================
+    // Internals
+    // ===========================================================================
+    /**
+     * The one 409 body, built in one place.
+     *
+     * Its call sites — the read guard, the renewal's re-assertion, and (#477)
+     * a settle whose guarded write found the claim gone — are answering the
+     * identical question, so a second hand-written message is a second chance
+     * for them to describe the same state differently.
+     *
+     * ⚠ IT STAYS DELIBERATELY UNSPECIFIC about which condition failed, including
+     * the claim-token one (#364). "Another executor may now own it" covers a
+     * second claim taken by THIS node as honestly as one taken by another
+     * machine, and the instruction the node has to act on — drop the work — is
+     * the same either way.
+     */
+    notHeldByNode(jobId, nodeId) {
+        return new common_1.ConflictException({
+            message: `Job ${jobId} is not held by node ${nodeId} with a live lease. It was reassigned, ` +
+                `re-claimed, already settled, or its lease expired and another executor may now own ` +
+                `it. Drop this work; do not retry.`,
+            details: { jobId, nodeId, reason: 'lease_not_held' },
+        });
+    }
+    /** `(createdById, name)` — the register-or-reattach anchor. */
+    findByName(userId, name) {
+        return this.prisma.workerNode.findUnique({
+            where: { createdById_name: { createdById: userId, name } },
+        });
+    }
+    /**
+     * The registered types a node may claim in THIS deployment, right now.
+     *
+     * ⚠ DELEGATED, AND THE DELEGATION IS THE POINT (#352). This used to be
+     * derived here, and `JobWorker`'s `system` mode derived the OPPOSITE answer
+     * from `registry.serverOnlyTypes()` — two independent derivations of one
+     * question, which agreed only for as long as node eligibility was a purely
+     * static property of a handler. The moment a type's eligibility acquired
+     * runtime gates (a settings switch, a capability probe), the two answers
+     * diverged and `db.backup.run` fell into the gap: no node was allowed to
+     * claim it and the `system` worker no longer claimed it either, so on such a
+     * deployment NOBODY TOOK THE BACKUPS.
+     *
+     * `NodeOffloadService` is now the one function, and the two executors read
+     * it in opposite directions — this one takes the set, the worker takes its
+     * complement — so they partition the queue by construction. Its header
+     * carries the full argument, including why it lives in `jobs/` rather than
+     * here (the nodes module imports the jobs module; the reverse would be a
+     * cycle).
+     */
+    nodeEligibleTypes() {
+        return this.offload.offeredTypes();
+    }
+    /** Whether a settled outcome means the job is coming back. */
+    willRetry(outcome) {
+        return outcome === 'retry-scheduled' || outcome === 'rate-limit-deferred';
+    }
+};
+exports.NodesService = NodesService;
+exports.NodesService = NodesService = NodesService_1 = __decorate([
+    (0, common_1.Injectable)(),
+    __param(0, (0, common_1.Inject)(index_2.PLATFORM_PRISMA)),
+    __param(7, (0, common_1.Optional)()),
+    __metadata("design:paramtypes", [Object, config_1.ConfigService,
+        index_3.JobClaimService,
+        index_9.JobTerminalService,
+        index_7.JobLeaseService,
+        index_5.JobHandlerRegistry,
+        index_6.NodeOffloadService,
+        node_settlement_ledger_1.NodeSettlementLedger])
+], NodesService);
+//# sourceMappingURL=nodes.service.js.map