fix(serverless): keep a log follow alive until the stream opens

[wilsonsilva]

Jira Ticket -> https://runware.atlassian.net/browse/RUNSERV-516

What

runware serverless apps logs <appId> --follow waits for the live stream to open instead of exiting when a gateway answers first.

Following an application that has not written a log entry yet ended by itself after about thirty seconds:

$ runware serverless apps logs slow-model-fede-2 --follow
ERRO The origin web server did not respond to Cloudflare within the allowed time. This typically means the origin is overloaded or a backend process is taking too long. code=internalServerError
$ echo $?
1

The log store holds the tail request open without writing its response headers, so the edge times the request out before the first entry arrives. TailLogs treated any non-200 status on the tail route as fatal, so the follow ended on its own. A stream that has already carried one entry is unaffected and survives minutes of silence.

A gateway status (502, 503, 504) on the tail route is now a *TailUnavailableError, and followLogs reconnects on it the way it already reconnects after the server ends a stream. Nothing has been delivered when the gateway answers, so a reconnect cannot repeat an entry. Every other status stays fatal.

$ runware serverless apps logs slow-model-fede-2 --limit 2 --follow
log stream unavailable: The origin web server did not respond to Cloudflare within the allowed time. This typically means the origin is overloaded or a backend process is taking too long.; waiting for the stream to open
^C
$ echo $?
0

The notice goes to stderr once per quiet spell rather than once per attempt: every attempt against a quiet application answers the same way, so a line every thirty-two seconds would be noise. A stream that opens resets it, so a later gateway answer is reported again.

Why

The acceptance criterion "--follow keeps streaming until interrupted" did not hold for an application that is quiet at the moment you start the follow. QA on dev reproduced the exit four times out of four, between thirty-three and thirty-six seconds, on two different applications. curl on /v1/logs/queries/runtime_tail/tail reproduces it with no CLI involved: HTTP/2 504, server: cloudflare, after 30.5 seconds, sixteen bytes. On the same quiet application the command now holds for 160 seconds and exits 0 on Ctrl-C, and a busy application still streams unchanged.

insights should also write its response headers when it accepts the connection, and that is the proper fix on the API side. This change means the CLI keeps its promise whichever way that goes, and it also covers an ordinary edge blip mid-follow.

Notes

• The failure is pre-first-byte by construction, which is what makes the reconnect safe. Proven on dev with a purpose-built application: fully idle from the start the follow died at thirty-three seconds, and started while the worker was logging the same follow ran 331 seconds and sat through 125 seconds of total silence at the end.
• --follow reconnects without a cap, as it already did for a stream the server ends. A permanently broken gateway therefore polls about every thirty-two seconds until interrupted.

Provisioning: none.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. To trigger a review, include coderabbit-review in the PR description. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: e149574e-851a-42ec-afb4-9d290630869a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}