From c5d59add8afa0db49ab91ec7b6f83156eda74c57 Mon Sep 17 00:00:00 2001 From: Rinse Date: Mon, 17 Aug 2026 11:13:38 +0000 Subject: [PATCH 1/2] chore(deps): upgrade @pkcprotocol/pkc-js 0.0.82 -> 0.0.83 --- package-lock.json | 8 ++++---- package.json | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package-lock.json b/package-lock.json index 156d0c3..aa8a589 100644 --- a/package-lock.json +++ b/package-lock.json @@ -16,7 +16,7 @@ "@oclif/plugin-help": "6.2.36", "@oclif/plugin-not-found": "3.2.73", "@oclif/table": "0.5.1", - "@pkcprotocol/pkc-js": "0.0.82", + "@pkcprotocol/pkc-js": "0.0.83", "dataobject-parser": "1.2.22", "decompress": "4.2.1", "env-paths": "2.2.1", @@ -5850,9 +5850,9 @@ } }, "node_modules/@pkcprotocol/pkc-js": { - "version": "0.0.82", - "resolved": "https://registry.npmjs.org/@pkcprotocol/pkc-js/-/pkc-js-0.0.82.tgz", - "integrity": "sha512-65bE+77b6wLrP62owYe1pCq3TEdmaKMRByqii5in/ikyHJpUEYd5dVKe/KFkTWTMV+1+kkMUC+hXgeRdPNIy0w==", + "version": "0.0.83", + "resolved": "https://registry.npmjs.org/@pkcprotocol/pkc-js/-/pkc-js-0.0.83.tgz", + "integrity": "sha512-vh6N/7hheXr7hmxLjn0GIsP6hPYkEg/ya96Q5ECjVV8Qy3Av6gJ92/k4TecjVC0C0NCHs/g77jYeWXHCNvgGSA==", "license": "GPL-3.0-or-later", "dependencies": { "@enhances/with-resolvers": "0.0.5", diff --git a/package.json b/package.json index 10fdfda..fa08ecd 100644 --- a/package.json +++ b/package.json @@ -119,7 +119,7 @@ "@oclif/plugin-help": "6.2.36", "@oclif/plugin-not-found": "3.2.73", "@oclif/table": "0.5.1", - "@pkcprotocol/pkc-js": "0.0.82", + "@pkcprotocol/pkc-js": "0.0.83", "dataobject-parser": "1.2.22", "decompress": "4.2.1", "env-paths": "2.2.1", From 26122102b3b437eb092dec94dd02f0f77fe402e8 Mon Sep 17 00:00:00 2001 From: Rinse Date: Mon, 17 Aug 2026 11:28:12 +0000 Subject: [PATCH 2/2] test(daemon): poll waitForKuboReady instead of a one-shot fetch in the KUBO_RPC_URL test startPkcDaemon resolves on the 'Communities in data path' banner, which does not mean kubo's HTTP API is listening: pkc-js rewrites kubo's Routing config and POSTs /shutdown on first connect, so the daemon restarts kubo around init. The single un-retried fetch could land in that window and fail with ECONNREFUSED on macOS CI. Every other kubo check in the suite already polls waitForKuboReady; this was the last bare one missed by the #95 fix. Closes #133 --- test/cli/daemon.test.ts | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/test/cli/daemon.test.ts b/test/cli/daemon.test.ts index 25a2d9f..7bdfce7 100644 --- a/test/cli/daemon.test.ts +++ b/test/cli/daemon.test.ts @@ -753,9 +753,13 @@ describe(`bitsocial daemon KUBO_RPC_URL env var`, async () => { try { const daemon = await startPkcDaemonWithDynamicPorts((e) => ["--pkcOptions.dataPath", randomDirectory(), "--pkcRpcUrl", e.rpcWsUrl]); daemonProcess = daemon.daemonProcess; - // Kubo should be reachable on the port configured via the injected KUBO_RPC_URL env var - const res = await fetch(`${daemon.kuboApiUrl}/bitswap/stat`, { method: "POST" }); - expect(res.status).toBe(200); + // Kubo should be reachable on the port configured via the injected KUBO_RPC_URL env var. + // Poll instead of a one-shot fetch: startPkcDaemon resolves on the "Communities in data + // path" banner, but pkc-js restarts kubo around init (it rewrites the Routing config and + // POSTs /shutdown on first connect), so a single fetch can land in the window where the + // API port refuses connections (issue #133, lineage #95). + const kuboReady = await waitForKuboReady(daemon.kuboApiUrl, 45000); + expect(kuboReady).toBe(true); } finally { await stopPkcDaemon(daemonProcess); }