[BUG] Failed HTTP Request Keeps Node Alive Until Timeout

[phroi]

Hello folks at CKB DevRel,

I noticed that a handled CCC HTTP request failure keeps a Node process alive until the request timeout expires.

Minimal Reproduction

import { ccc } from "@ckb-ccc/core";

globalThis.fetch = async () => {
  throw new Error("unavailable");
};

const client = new ccc.ClientPublicTestnet({
  url: "https://a.invalid/",
  fallbacks: [],
  timeout: 1000,
});

await client.getTip().catch(() => console.log("caught"));

And to run it:

/usr/bin/time -f 'elapsed=%e' node repro.mjs

Behavior

fetch rejects immediately and the error is handled, so the process should exit immediately after printing caught. Instead, it remains alive until the configured one-second timeout expires:

caught
elapsed=1.30

The HTTP transport clears its abort timer only after fetch and response parsing succeed. A rejection skips that cleanup and leaves the timer active until it fires.

Proposed Solution

Clear the timer in finally so every exit path runs the cleanup:

const aborter = new AbortController();
const abortTimer = setTimeout(() => aborter.abort(), this.timeout);

try {
  return await (
    await fetch(this.url, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(payload),
      signal: aborter.signal,
    })
  ).json();
} finally {
  clearTimeout(abortTimer);
}

Tests should cover a rejected fetch, rejected JSON parsing, success, and timeout.

Environment

• @ckb-ccc/core@1.17.0
• Node.js 24.18.0
• Linux

Impact

A handled HTTP failure can delay a finite Node command, test, or worker until the request timeout expires. With the default timeout this can add about 30 seconds, and repeated failures can leave multiple active timers.

Keep up the Great Work
Phroi %47

[Hanssen0]

Appreciated your feedback! This is noted but not planned to be fixed due to its low impact. A simple main wrapper should help bypass this problem.

async function main() {
}

await main().finally(() => process.exit(0));

[phroi]

Why asking dev to make a workaround?

The fix has no API impact and it is as simple as a proper:

try {
...
} finally {
 // do the cleanup in the proper place
}

Phroi

[Hanssen0]

Why asking dev to make a workaround?

The fix has no API impact and it is as simple as a proper:

try {
...
} finally {
// do the cleanup in the proper place
}
Phroi

The WebSocket transport is still recommended & default so the wrapper is still needed before #444.

[Hanssen0]

The fix has no API impact and it is as simple as a proper:

I completely agree it's a quick one-liner. However, the context switching & branch management & decision-making are where the real mental energy goes. To focus on more coherent tasks, I prefer to assign low-priority tasks to a specific time to minimise these additional burdens.

That being said, if this is pressing for you, I would be happy (and grateful) to review & merge a PR that has already been prepared by an experienced developer like you.

I just wanted to explain why I made this decision, to avoid any problems caused by miscommunication now or in the future.

[Hanssen0]

Should be fixed by #487

[phroi]

Should be fixed by #487

Thanks! Confirmed on dev, not released yet tho

Phroi