Please publish 1.2.0: install failures and silently dropped security alerts in 1.1.2
Summary
The published npm release, 1.1.2, has two issues observed when scanning a dependency tree containing more than 1,000 packages: a single transient connection error aborts bun install, and results from in-flight requests can be silently dropped, causing security alerts to be under-reported.
Both appear to be addressed on main, but installing directly from git is not a straightforward workaround.
Please publish 1.2.0 so downstream users can access these fixes.
Install failures caused by transient connection errors
In authenticated mode, createScanner is configured with maxBatchLength: 1 and maxSending: 30. This produces one POST /v0/purl request per package, with approximately 30 concurrent requests.
fetchStrategy has no retry handling, so a single connection reset propagates to Bun and aborts the installation:
error: Security scanner failed: The socket connection was closed unexpectedly.
error: security scanner failed: ScannerFailed
This reproduced across repeated attempts, shortly after scanning began.
Testing the endpoint directly with 300 requests through 30 concurrent workers produced 296 successful requests, three ECONNRESET errors and one HTTP 502 response. That is approximately a 1.3% transient failure rate in this test. Requiring every request to succeed without retries makes larger scans particularly fragile.
Adding bounded retries—up to five attempts with exponential backoff—and changing nothing else allowed the same scan to complete reliably in approximately eight seconds.
The unauthenticated path also issues one request per purl through purls.map and Promise.all, without retries, so the same failure mode exists without SOCKET_API_KEY.
The endpoint accepts a components array, so batching would also substantially reduce the number of API requests.
Results from in-flight requests are silently dropped
scanner-factory.ts drains results by yielding the current artifacts array and assigning a new empty array to artifacts.
Existing in-flight fetchStrategy calls retain a reference to the previous array. Results pushed into that array after the reassignment can therefore be lost instead of being yielded.
With concurrent flights, this causes substantial under-reporting. In testing, 1.1.2 returned significantly fewer alerts than an SDK-based scan of the same package set.
The installation can then proceed with an incomplete set of security warnings, without indicating that results were dropped.
The rewrite on main documents this reference-handling hazard and addresses it by draining the existing array with splice(0).
Main addresses these issues, but is difficult to consume
The implementation on main, with package version 1.2.0, uses @socketsecurity/sdk’s batchPackageStream with chunkSize: 1024, concurrencyLimit: 10 and SDK-level retry handling, including for ECONNRESET.
It also keeps a stable artifacts array, retains every flight for the final drain, and replaces the bare .finally() handling that could produce an unhandled rejection.
Testing @socketsecurity/sdk@4.1.4 using the same approach and package set returned an artifact for every input package and the full set of alerts, with no connection errors, in approximately one second.
Installing from git is not a straightforward workaround: dist/ is not committed, the package’s files configuration includes only dist, prepare runs the full repository/fleet bootstrap chain, and prepublishOnly intentionally fails outside the project’s CI.
Requested action
Please publish 1.2.0 to npm.
This would make the existing fixes available through normal installation and avoid users needing to maintain a custom scanner or disable install-time scanning to unblock dependency installation.
Environment
Bun 1.3.14 on Linux x64.
@socketsecurity/bun-security-scanner 1.1.2.
Authenticated mode with SOCKET_API_KEY configured.
Bun workspaces project with more than 1,000 packages.
linker = "hoisted".
Please publish 1.2.0: install failures and silently dropped security alerts in 1.1.2
Summary
The published npm release, 1.1.2, has two issues observed when scanning a dependency tree containing more than 1,000 packages: a single transient connection error aborts bun install, and results from in-flight requests can be silently dropped, causing security alerts to be under-reported.
Both appear to be addressed on main, but installing directly from git is not a straightforward workaround.
Please publish 1.2.0 so downstream users can access these fixes.
Install failures caused by transient connection errors
In authenticated mode, createScanner is configured with maxBatchLength: 1 and maxSending: 30. This produces one POST /v0/purl request per package, with approximately 30 concurrent requests.
fetchStrategy has no retry handling, so a single connection reset propagates to Bun and aborts the installation:
error: Security scanner failed: The socket connection was closed unexpectedly.
error: security scanner failed: ScannerFailed
This reproduced across repeated attempts, shortly after scanning began.
Testing the endpoint directly with 300 requests through 30 concurrent workers produced 296 successful requests, three ECONNRESET errors and one HTTP 502 response. That is approximately a 1.3% transient failure rate in this test. Requiring every request to succeed without retries makes larger scans particularly fragile.
Adding bounded retries—up to five attempts with exponential backoff—and changing nothing else allowed the same scan to complete reliably in approximately eight seconds.
The unauthenticated path also issues one request per purl through purls.map and Promise.all, without retries, so the same failure mode exists without SOCKET_API_KEY.
The endpoint accepts a components array, so batching would also substantially reduce the number of API requests.
Results from in-flight requests are silently dropped
scanner-factory.ts drains results by yielding the current artifacts array and assigning a new empty array to artifacts.
Existing in-flight fetchStrategy calls retain a reference to the previous array. Results pushed into that array after the reassignment can therefore be lost instead of being yielded.
With concurrent flights, this causes substantial under-reporting. In testing, 1.1.2 returned significantly fewer alerts than an SDK-based scan of the same package set.
The installation can then proceed with an incomplete set of security warnings, without indicating that results were dropped.
The rewrite on main documents this reference-handling hazard and addresses it by draining the existing array with splice(0).
Main addresses these issues, but is difficult to consume
The implementation on main, with package version 1.2.0, uses @socketsecurity/sdk’s batchPackageStream with chunkSize: 1024, concurrencyLimit: 10 and SDK-level retry handling, including for ECONNRESET.
It also keeps a stable artifacts array, retains every flight for the final drain, and replaces the bare .finally() handling that could produce an unhandled rejection.
Testing @socketsecurity/sdk@4.1.4 using the same approach and package set returned an artifact for every input package and the full set of alerts, with no connection errors, in approximately one second.
Installing from git is not a straightforward workaround: dist/ is not committed, the package’s files configuration includes only dist, prepare runs the full repository/fleet bootstrap chain, and prepublishOnly intentionally fails outside the project’s CI.
Requested action
Please publish 1.2.0 to npm.
This would make the existing fixes available through normal installation and avoid users needing to maintain a custom scanner or disable install-time scanning to unblock dependency installation.
Environment
Bun 1.3.14 on Linux x64.
@socketsecurity/bun-security-scanner 1.1.2.
Authenticated mode with SOCKET_API_KEY configured.
Bun workspaces project with more than 1,000 packages.
linker = "hoisted".