Not Every Unreachable Connector Means the Same Thing in an Unattended Run

Splitting the wait budget by state removes most of the waiting

Once you can classify, you only wait on connecting. Give the wait an explicit budget and poll interval, and return a verdict when the budget runs out.

// resolver.mjs (continued) — capability resolution with a budget
export async function resolve(toolName, opts) {
  const { snapshotOf, waitBudgetMs = 20000, pollMs = 2000, sleep } = opts;
  const deadline = Date.now() + waitBudgetMs;
  let waitedMs = 0;
 
  for (;;) {
    const state = classify(toolName, await snapshotOf());
 
    if (state === READY) return { state, waitedMs };
 
    // The two states time cannot fix: return without waiting
    if (state === UNAUTHENTICATED || state === ABSENT) return { state, waitedMs };
 
    // Would the next poll overrun the budget? Then stop here
    if (Date.now() + pollMs > deadline) {
      return { state: CONNECTING, waitedMs, timedOut: true };
    }
    await sleep(pollMs);
    waitedMs += pollMs;
  }
}

sleep arrives as a parameter so tests can swap in a virtual clock. Code that waits on real time does not get tested, and untested code breaks without telling anyone.

To see the effect, I built a simulation around twelve tools. Seven are usable from the start, one appears on the fourth poll, one stays mid-handshake to the end, and three are waiting on authorization. Budget: 20 seconds. Poll interval: 2 seconds.

Two implementations were compared. A ignores the three states and treats anything missing from the inventory as "might still arrive," waiting uniformly. B routes through the classifier above.

A no states : total wait 86000 ms / 8 ready
B 3 states  : total wait 26000 ms / 8 ready
delta: 60000 ms ( 69.8 % less )

Both runs end with the same eight usable tools. The extra sixty seconds A spent produced nothing at all: three unauthenticated connectors, twenty seconds each, entirely discarded — 69.8% of the total wait, roughly seven-tenths of it, contributing nothing.

The numbers come from a virtual-clock simulation, so a real environment will shift them with different poll intervals, budgets, and connector counts. The structure holds regardless: the more unauthenticated connectors you have, the longer the undifferentiated implementation waits, linearly — each additional unauthenticated connector adds the full 20-second budget, and every one of those seconds is waste.

If you have no basis for a starting value, I would recommend a 15–20 second budget with a 2-second poll interval; that is what I run. Stretching the budget to 60 seconds recovered exactly one slow connector, which does not pay for itself in a scheduled task with a hard runtime ceiling. Tightening it to 5 seconds, on the other hand, drops the connector that needed four polls — six seconds — to come online. That six-second figure is what set the floor.

Move the capability check from the start of the run to the moment of use

Three states will not help if you check in the wrong place. The common shape is to enumerate tools once at the top of the run and reuse that answer everywhere.

// ❌ Frozen at the entrance — slow connectors are lost permanently
const available = await listTools();
const canUseDrive = available.includes("mcp__google-drive__search");
// ...ten minutes of other work happens here...
if (canUseDrive) { /* by now it is almost certainly usable */ }

In many runtimes, connectors continue coming online after the run begins. The opening snapshot is a photograph of one instant. You are making a decision that matters ten minutes from now using a picture taken ten minutes ago.

The fix is unglamorous: defer the decision until just before you need it.

// ✅ Resolve at the point of use, with a short-lived cache
const cache = new Map();
 
async function capability(toolName, ttlMs = 60000) {
  const hit = cache.get(toolName);
  if (hit && Date.now() - hit.at < ttlMs) return hit.value;
 
  const value = await resolve(toolName, { snapshotOf, sleep: realSleep });
  // "ready" and "absent" are stable for a while.
  // "connecting" can flip at any moment, so give it a short life
  const at = value.state === CONNECTING ? Date.now() - ttlMs + 5000 : Date.now();
  cache.set(toolName, { value, at });
  return value;
}

Varying the cache lifetime by state is the practical heart of it. ready and absent hold steady for tens of seconds; connecting may become ready on the very next tick. Give them one shared TTL and you will keep ignoring a connector that already finished starting up.

Keying that cache by tool was my mistake

I ran that cache for the better part of a year before I printed a breakdown of where the waiting went and stopped short. I had been waiting on tools from the same server one at a time.

Neither connecting nor unauthenticated is a property of a tool. Both belong to the server. Yet I had keyed the cache on toolName, so a run that touched three tools on one server paid the budget three times to learn the same fact. Worse, the connecting entry is deliberately short-lived, so by the time the second tool came around the entry had already expired and a full-price wait began again. Keeping that entry short-lived was the right call on its own — it just backfired because the key was cut at the wrong grain.

I measured the cost with a virtual clock: four servers, three tools each, twelve steps. Two servers ready from the start, one coming up after six seconds, one still connecting at the end.

A keyed by tool:   total wait 66000 ms / 9 ready
B keyed by server: total wait 26000 ms / 9 ready
difference: 40000 ms (60.6 % less waiting)

Both runs ended with the same nine usable tools. The forty-second gap is one still-connecting server asked the same question three times — three tools' worth of budget (20s × 3) spent where one answer would have done. Again, nothing was gained by the extra waiting.

Changing the key turned out to be more than a one-line edit. The conclusions you do not wait on can be shared per server, but ready cannot. A server can be answering while one particular tool is simply not offered in this run. That a server is alive and that the tool you want is in your hands are two different claims.

// ✅ Share the non-waiting conclusions (connecting / unauthenticated / absent) per server
const serverCache = new Map();
 
async function capability(toolName, ttlMs = 60000) {
  const key = serverOf(toolName);
  const hit = serverCache.get(key);
 
  // Re-check "ready" per tool: a live server does not guarantee
  // that this particular tool is being served
  if (hit && Date.now() - hit.at < ttlMs && hit.value.state !== READY) {
    return hit.value;
  }
 
  const value = await resolve(toolName, { snapshotOf, sleep: realSleep });
  const at = value.state === CONNECTING ? Date.now() - ttlMs + 5000 : Date.now();
  serverCache.set(key, { value, at });
  return value;
}

Decide what to wait for per server; decide what is usable per tool. Get the grain wrong and the logic stays correct while the bill quietly keeps arriving. Since that day I've made a habit of questioning a cache's key before its lifetime whenever I add one. I may be missing something, but the same mix-up seems to be waiting inside retry ceilings and rate-limit bookkeeping too.

Unauthenticated will not heal, and that asymmetry belongs to unattended runs

While you are working interactively, an expired grant is a non-event. A prompt appears, you approve in the browser, you are back in under a minute.

In an unattended run, that path does not exist at all. The handshake presumes a human at a browser, so the task cannot even begin it. Miss this and you will design the connector as a transient fault worth retrying — and each retry stretches the run without changing the outcome.

So the accurate framing is that unauthenticated is not a failure but a handoff. Three rules have become my defaults:

1. On detection, abandon only the steps that depend on that connector — never the whole run
2. Let independent steps run to completion and produce their output
3. State plainly, in the final output, which connector was in which state and what it blocked

Skip the third and whoever picks this up ends up digging through logs anyway. Treating the output of an unattended run as a handoff note for the next human makes the content obvious. The same reasoning appears in When Claude Declines a Request on Safety Grounds, What Should an Unattended Pipeline Return? — only the reason for the refusal differs, safety judgment there, missing authorization here.

Fall back, halt, or hand it to a person

With three states in hand, decide each step's default behavior up front. Improvising this per step is how implementations drift.

// Declare steps: required or not, and whether a fallback exists
const steps = [
  { id: "fetch-metrics", tool: "mcp__analytics__query", required: true,  fallback: null },
  { id: "post-summary",  tool: "mcp__chat__send",      required: false, fallback: "write-file" },
  { id: "archive",       tool: "mcp__storage__put",    required: false, fallback: "write-file" },
];
 
async function planStep(step) {
  const { state } = await capability(step.tool);
 
  if (state === READY) return { action: "run" };
 
  if (state === UNAUTHENTICATED) {
    // Waiting changes nothing. Halt if required, divert if optional
    return step.required
      ? { action: "abort",    reason: `${step.tool} needs authorization` }
      : { action: "fallback", to: step.fallback, reason: "not authorized; using fallback" };
  }
 
  if (state === CONNECTING) {
    // Budget exhausted while still handshaking. A later run may succeed
    return step.required
      ? { action: "retry-next-run", reason: "still starting when budget ran out" }
      : { action: "skip",           reason: "still starting; skipped this run" };
  }
 
  // absent
  return step.required
    ? { action: "abort",    reason: `${step.tool} is not connected` }
    : { action: "fallback", to: step.fallback, reason: "not connected; using fallback" };
}

unauthenticated and absent share the abort action for required steps, yet carry different wording on purpose: the reader's next move differs. One means redo the authorization; the other means add the connection. Two ways of saying "it stopped" — but only one of them tells the reader exactly what to do next, and that difference is measured in recovery time.

Log which state failed, not that something failed

The biggest win from three states was not the shorter runtime. It was that the logs became readable.

// Always emit one record at the end with the per-state breakdown
function summarize(decisions) {
  const byState = decisions.reduce((acc, d) => {
    acc[d.state] = (acc[d.state] || 0) + 1;
    return acc;
  }, {});
  return {
    ts: new Date().toISOString(),
    ran: decisions.filter(d => d.action === "run").length,
    blocked_by_auth: decisions
      .filter(d => d.state === "unauthenticated")
      .map(d => serverOf(d.tool)),
    still_connecting: decisions
      .filter(d => d.state === "connecting")
      .map(d => serverOf(d.tool)),
    absent: decisions.filter(d => d.state === "absent").map(d => serverOf(d.tool)),
    byState,
  };
}

A sample record:

{
  "ts": "2026-08-23T03:00:12.481Z",
  "ran": 8,
  "blocked_by_auth": ["analytics", "chat", "storage"],
  "still_connecting": ["search"],
  "absent": [],
  "byState": { "ready": 8, "unauthenticated": 3, "connecting": 1 }
}

Compare that with "No matching capability was found" and the next action picks itself. Names under blocked_by_auth mean re-running authorization gets you a working task tomorrow. Only still_connecting means extending the budget a little, or moving that step later in the order. Anything under absent means the configuration itself needs attention.

For the wider question of what an unattended run should record, Logged as success, but it produced nothing — stopping silent failures in Cowork scheduled tasks with end-of-run assertions works through the assertion shape. The per-state breakdown here feeds straight into those assertions.

Two things the implementation got wrong before it got right

Two results contradicted what I expected.

First, heavier retries lowered the completion rate for some steps. Intuitively, more attempts should catch more opportunities. But retrying against an unauthenticated connector catches nothing while consuming runtime. Runtime is capped, so wasted waiting early pushes legitimate work out of the window. Adding retries reduced the total number of completed steps. Undifferentiated waiting is not merely slow — it steals time from steps that would have succeeded.

Second, my tests never reproduced the inventory growing mid-run. The fixture pinned the tool list, so the connecting → ready transition was never exercised. Adding a virtual clock and a case where the tool appears on the fourth poll immediately surfaced a bug in the cache lifetime: a connector that had just come online stayed invisible for the rest of the TTL.

// Reproduce "arrives late" with a virtual clock
let now = 0;
const sleep = ms => { now += ms; return Promise.resolve(); };
Date.now = () => now;   // swapped only inside the test
 
let polls = 0;
const lateArrival = async () => {
  polls++;
  return polls >= 4
    ? { readyTools: ["mcp__x__a"], pendingServers: [], unauthenticatedServers: [] }
    : { readyTools: [], pendingServers: ["x"], unauthenticatedServers: [] };
};
 
// → { state: 'ready', waitedMs: 6000 }  polls = 4
console.log(await resolve("mcp__x__a", { snapshotOf: lateArrival, sleep }));

Tests that wait on real time are slow, so they stop being written; because they are not written, the transition path goes unverified. A virtual clock breaks that chain — six seconds of waiting verified in milliseconds.

On halting and recovery more broadly, Why Cowork Scheduled Tasks Stop Mid-Run and How to Recover covers ground that pairs well with this.

If you try one thing first

Open the log of an unattended task you are running right now and find the line that stands for "it was not available." If that line carries no connector name and no state, the first step is adding exactly that.

Resolvers, budgets, and caches can all come later. A state you never recorded, though, cannot be recovered after the fact. I arrived at this three-state split only because I first built the habit of writing down what had been missing, back when I still had no idea why.