HTTP trigger disappears after duplicate worker registration is rejected

Versions

• iii engine: 0.22.1
• Node SDK: 0.22.0

Problem

When deploying on Railway we have been seeing some issues:

A rolling deployment starts worker B before worker A disconnects. Both workers register the same function and HTTP trigger. The engine accepts B's function but rejects B's trigger because A still owns the route.

When A disconnects, the engine removes the route. B remains connected, but its previously rejected trigger is not retried, so the endpoint returns 404 until B reconnects or the trigger provider re-registers.

Minimal reproduction

import { registerWorker } from "iii-sdk";

const instance = process.env.INSTANCE;
const iii = registerWorker("ws://127.0.0.1:49134", {
  workerName: "http-handoff-repro",
});

const ref = iii.registerFunction("repro::health", async () => ({
  status_code: 200,
  body: { instance },
}));

iii.registerTrigger({
  type: "http",
  function_id: ref.id,
  config: { api_path: "/handoff", http_method: "GET" },
});

1. Start the engine.
2. Start worker A with INSTANCE=A node worker.mjs.
3. Start worker B with INSTANCE=B node worker.mjs without stopping A.
4. B logs a route conflict for GET /handoff.
5. Stop A while B remains connected.
6. GET /handoff now returns 404.
7. Restart B. The route returns 200 again.

The failure is not limited to Railway. Railway's rollout order makes it easy to reproduce because it starts the replacement before signaling the old container. In one measured handoff, B registered 1.49 seconds before A disconnected. Every HTTP trigger on B was rejected, then the routes disappeared when A disconnected.

Expected behavior

Registering an identical trigger declaration from another live worker should be idempotent. If the trigger type, configuration, and function ID match, the route should remain registered while at least one matching worker remains connected.

A declaration that reuses the same route for a different function ID or different configuration should continue to fail as a real conflict.

This would make rolling deployments and multiple replicas safe without allowing unrelated workers to take over routes.

Possible related issue: #2050