fix(push): prevent hang and tag race in apify push (#1131) by l2ysho · Pull Request #1134 · apify/apify-cli

l2ysho · 2026-05-14T13:38:05Z

Fixes #1131.

apify push had two reliability issues:

Hang after build stream ends. If the build log stream closed before the build reached a terminal status, push waited forever. Now polls build
status with a cap from --wait-for-finish (defaults to no cap when unset, but exits cleanly on terminal status).
Tag race. Push could exit 0 before the latest tag was applied, so a following actor.start({ build: 'latest' }) would race. Now polls for the
tag to point at the new build (30s budget) before exiting.

Also:

parseWaitForFinishMillis extracted and unit-tested; treats negative/NaN as "no cap".
--wait-for-finish 0 now means "don't wait" (was previously equivalent to unset).
Exit code is BuildTimedOut when build is still READY/RUNNING at the cap.
using _signalHandler moved to cover the polling loops, so Ctrl+C aborts the build platform-side.

Resolves an issue where waitForFinishMillis could be NaN for invalid flag inputs, leading to unexpected behavior.

…can-exit-0-before-the-latest-tag-is-applied

vladfrangu · 2026-05-18T16:08:37Z

Ok this test is kinda useless :D

vladfrangu · 2026-05-18T16:10:07Z

 			// @ts-expect-error FIX THESE TYPES 😢
 		} else if (build.status === ACTOR_JOB_STATUSES.READY) {
 			warning({ message: 'Build is waiting for allocation.' });
+			process.exitCode = CommandExitCodes.BuildTimedOut;


This is technically wrong, if I pass in apify push --waitForFinish=5 it should not give me a non-0 exit code when the timer ran out

vladfrangu · 2026-05-18T16:13:36Z

+		// ended early, timeout hit). Poll so the status branches below see the
+		// real outcome. With no --wait-for-finish, the flag documents "waits
+		// forever", so poll without a deadline.
+		const deadline = waitForFinishMillis === undefined ? Infinity : Date.now() + waitForFinishMillis;


I feel like the deadline should be computed right before starting the build, not after waiting for the outputLog to finalizr/crash.

also, won't this cause a double-wait? Imagine an actor that takes 4minutes to build, if --waitForFinish is set to 30s, we print for 29s then connection dies for the log stream, we wait another 30s after? Ideally we calculate a delta between build start, and log end, and wait out the remaining time, if any, right?

vladfrangu · 2026-05-18T16:18:23Z

+		if (build.status === ACTOR_JOB_STATUSES.SUCCEEDED && buildTag) {
+			// 30s budget is independent of --wait-for-finish: the build is already
+			// done, we're only waiting on the platform to update the tag pointer.
+			const tagDeadline = Date.now() + 30_000;


30s is wayy too much, i'd bail out after 5 max. Also lets print out a message that we are "applying the build tag" (even tho the console does it) just so users know why their terminal is hanging

vladfrangu · 2026-05-18T16:20:04Z

+export function parseWaitForFinishMillis(flag: string | undefined): number | undefined {
+	if (flag === undefined) return undefined;
+	const parsed = Number.parseInt(flag, 10);
+	if (!Number.isFinite(parsed) || parsed < 0) return undefined;


mmmm, can you compare what happens right now with --waitForFinish=0 vs this PR? It's a use case we should support imo (fire-and-forget)

in actual version it is ignored, it just show you whole build log to the end. In PR it ends with

Actor build detail https://console.apify.com/actors/k3Ew4ttdaIThULhmR#/builds/0.25.6 Actor detail https://console.apify.com/actors/k3Ew4ttdaIThULhmR Warning: Build is still running.

…can-exit-0-before-the-latest-tag-is-applied

When --wait-for-finish is passed explicitly, hitting the cap with the build still in READY/RUNNING is the user's chosen bounded wait, not a failure. Only surface BuildTimedOut for these states when the flag was omitted.

Compute a single deadline before the build call and share it between log streaming and the status poll loop. Previously the poll loop started a fresh --wait-for-finish budget after outputJobLog returned, so a log stream that died near the cap could double the user's wait.

Cut the post-build tag-apply budget from 30s to 5s, print a status line so users see why push is still waiting, and drop the non-zero exit code on tag-miss — the build itself succeeded, a lagging tag pointer is a warning, not a failure.

patrikbraborec

I think that the current behavior is better, if I understand it correctly:

After the build log stream ends, push now polls the build's actual status until it reaches a
terminal state, instead of trusting the stream (which could close early and leave push waiting forever).

Also, this will help with follow ups: #1135

LGTM

Skip the post-build tag-apply wait when --wait-for-finish=0 so the flag is truly fire-and-forget regardless of how fast the build completed. Document the 0 semantics in the flag help text. Also picks up stale doc regeneration from #1128 (--describe / --search wording).

…can-exit-0-before-the-latest-tag-is-applied

The previous guard was unreachable: when --wait-for-finish is unset, the poll loop only exits on terminal status, so READY/RUNNING branches were dead. Switch the guard to `waitForFinishMillis !== 0` so finite caps that hit the deadline surface a non-zero exit code (useful for scripts), while fire-and-forget (--wait-for-finish=0) still returns 0 on READY. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-authored-by: Edyta <142720610+szaganek@users.noreply.github.com>

l2ysho self-assigned this May 14, 2026

l2ysho added the t-dx Issues owned by the DX team. label May 14, 2026

l2ysho linked an issue May 14, 2026 that may be closed by this pull request

apify push can hang indefinitely and can exit 0 before the latest tag is applied #1131

Open

github-actions Bot added this to the 140th sprint - Tooling team milestone May 14, 2026

github-actions Bot added the tested Temporary label used only programatically for some analytics. label May 14, 2026

fix(actors): correctly parse waitforfinish flag

07e801a

Resolves an issue where waitForFinishMillis could be NaN for invalid flag inputs, leading to unexpected behavior.

l2ysho force-pushed the 1131-apify-push-can-hang-indefinitely-and-can-exit-0-before-the-latest-tag-is-applied branch from fa017eb to 07e801a Compare May 14, 2026 22:00

l2ysho added 8 commits May 18, 2026 11:50

Merge branch 'master' into 1131-apify-push-can-hang-indefinitely-and-…

cfe0e26

…can-exit-0-before-the-latest-tag-is-applied

extract parsing function and add regression tests

d9bf8ed

add pooling loop for push

b1d8b3e

fix default pooling

9e26c3e

fix race

d8e957b

fix 0 hangs forever

1cac10f

cap loop

1867aca

fix minor findings

5a40540

l2ysho marked this pull request as ready for review May 18, 2026 12:11

l2ysho requested a review from vladfrangu as a code owner May 18, 2026 12:11

l2ysho requested review from DaveHanns and patrikbraborec May 18, 2026 12:11

vladfrangu requested changes May 18, 2026

View reviewed changes

l2ysho added 5 commits May 25, 2026 16:30

Merge branch 'master' into 1131-apify-push-can-hang-indefinitely-and-…

4636b16

…can-exit-0-before-the-latest-tag-is-applied

remove test

5d12062

patrikbraborec approved these changes May 27, 2026

View reviewed changes

l2ysho requested a review from szaganek as a code owner May 27, 2026 08:46

Merge branch 'master' into 1131-apify-push-can-hang-indefinitely-and-…

f744e11

…can-exit-0-before-the-latest-tag-is-applied

szaganek reviewed May 27, 2026

View reviewed changes

Comment thread src/commands/actors/push.ts Outdated

l2ysho and others added 2 commits May 27, 2026 09:13

Update src/commands/actors/push.ts

f00ada8

Co-authored-by: Edyta <142720610+szaganek@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(push): prevent hang and tag race in apify push (#1131)#1134

fix(push): prevent hang and tag race in apify push (#1131)#1134
l2ysho wants to merge 18 commits into
masterfrom
1131-apify-push-can-hang-indefinitely-and-can-exit-0-before-the-latest-tag-is-applied

l2ysho commented May 14, 2026 •

edited

Loading

Uh oh!

vladfrangu May 18, 2026

Uh oh!

vladfrangu May 18, 2026

Uh oh!

vladfrangu May 18, 2026

Uh oh!

vladfrangu May 18, 2026

Uh oh!

vladfrangu May 18, 2026

Uh oh!

l2ysho May 27, 2026

Uh oh!

patrikbraborec left a comment •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

l2ysho commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vladfrangu May 18, 2026

Choose a reason for hiding this comment

Uh oh!

vladfrangu May 18, 2026

Choose a reason for hiding this comment

Uh oh!

vladfrangu May 18, 2026

Choose a reason for hiding this comment

Uh oh!

vladfrangu May 18, 2026

Choose a reason for hiding this comment

Uh oh!

vladfrangu May 18, 2026

Choose a reason for hiding this comment

Uh oh!

l2ysho May 27, 2026

Choose a reason for hiding this comment

Uh oh!

patrikbraborec left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

l2ysho commented May 14, 2026 •

edited

Loading

patrikbraborec left a comment •

edited

Loading