`datasets get-items` finishes but never exits — leaked keep-alive sockets pin the process (1.6.1 & 1.6.2)

[supersalestesting26]

Describe the bug

apify datasets get-items <id> --format json > out.json downloads the dataset and writes the complete output file, but the process then never exits. It sits idle indefinitely (we observed processes alive ~3 hours, state ep_poll, zero CPU) until killed.

This wedges any non-interactive/automation use (CI jobs, agent pipelines, cron) that waits for the command to finish — in our case it silently hung long-running automation sessions for hours.

Looks like the same class of bug as #1131 (apify push hang, fixed in May), but in datasets get-items.

Reproduction

timeout 60 apify datasets get-items <DATASET_ID> --format json > out.json; echo "exit=$?"; wc -c out.json

Result, 6/6 attempts on our machine: exit=124 (killed by timeout) with out.json complete and byte-identical to a successful fetch. Reproduces on:

• apify-cli 1.6.2 (e7cdb33), node-22.22.2, linux-x64, installed via npm
• apify-cli 1.6.1 (91d9a13), same environment (fresh npm install apify-cli@1.6.1)
• APIFY_CLI_DISABLE_TELEMETRY=1 does not help

Both versions were freshly installed in June 2026, so a recently published transitive dependency may be the trigger (an older install of the CLI on the same machine did not hang before being upgraded on 2026-06-04).

Diagnosis

After the output file is fully written, the node process keeps two ESTABLISHED keep-alive TLS connections open, which keep the event loop alive forever:

$ ss -tnp | grep pid=<PID>
ESTAB 0 0 <redacted>:33894 52.27.39.229:443  users:(("node",pid=<PID>,fd=22))   # *.segment.com (telemetry)
ESTAB 0 0 <redacted>:34204 34.201.161.226:443 users:(("node",pid=<PID>,fd=21))  # api.apify.com

(Endpoints identified via their TLS certificates.) Neither socket is closed/unref'd after the command's work completes, so node never reaches an empty event loop. Disabling telemetry doesn't fix it because the api.apify.com keep-alive socket alone is enough to pin the process.

Expected behavior

The process exits with code 0 once the dataset has been written, like other subcommands do — e.g. by closing/unref'ing the HTTP agents or calling process.exit() after flushing, as was done for push in #1131.

Workaround

Wrap the command in timeout and treat exit 124 + complete output file as success:

timeout 120 apify datasets get-items <id> --format json > out.json

System information

• apify-cli/1.6.2 (e7cdb33) and 1.6.1 (91d9a13)
• node v22.22.2, npm install
• Ubuntu Linux 6.8.0-111-generic, x64

[supersalestesting26]

Update after deeper investigation — two corrections and one new data point:

1. Not dependency freshness — it's a race. I wrote that an older install "did not hang"; that's wrong. On the same machine and install, two invocations of datasets get-items 11 seconds apart behaved differently: the first exited normally in ~2s, the second (same dataset, output redirected to a file) hung forever. Two earlier invocations minutes before also exited promptly. So the leaked keep-alive sockets are a timing-dependent race in connection cleanup, not a regression in a specific version — which also explains why nobody else has reported it: interactive users just get their data and never notice the process lingering.

2. Hang rate when scripted is near-100% here. In standalone scripted runs on this box (output redirected to a file, non-TTY stdout), it hung 9/9 across apify-cli 1.6.1/1.6.2 and apify-client 2.23.3/2.23.4 pinned. So if the race has a bias, non-TTY/redirected output seems to make the leak much more likely.

Environment unchanged from the report (node v22.22.2, linux x64). Happy to run any diagnostic build/flag you want against this setup.