fix(job): fetch log tail for nested jobs by job id, not dotted runId (#787) - #788
Conversation
…787) Nested Queue jobs (inside a flow, child row jobs) carry a dotted runId (<parent>.<child>.<id>) that matches zero Storage events, so logTail came back empty. Resolve the events key via a shared resolve_events_run_id(): job id first, else the last segment of a dotted runId. Used by the job service log tail and the serve job log stream.
Two test comments still said that the runId is the lookup key. The assertions below them expect the job id. The gotcha said that job run --wait failure tails were affected. job run starts only top-level jobs, where the runId equals the job id, so they were not affected.
keboola-pr-reviewer-bot
left a comment
keboola-pr-reviewer-bot
left a comment
There was a problem hiding this comment.
Verdict: auto_approve (risk 2/5) · profile keboola-mcp-server
Well-tested bug fix; correct and low-risk.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| ## `logTail` was empty for nested jobs | ||
|
|
||
| Fixed (since vNEXT). A job inside a flow, or a child row job of a row-based component, has a |
There was a problem hiding this comment.
🔍 Update the job-debugging playbook
The debugging guidance still suggests a plain job detail followed by job run for logs. Plain detail omits logs; a tail-enabled detail now retrieves them from the existing nested job without rerunning it.
Was this helpful? React with 👍 or 👎 to provide feedback.
The keboola-expert tool matrix told agents to start a new run of a failed job to see its logs. A new run repeats the work, and a writer can send its data again. job detail --log-tail-lines reads the logs of the finished job. With this PR it also works for jobs inside a flow.
Dismissing prior approval — a new commit was pushed and this review was for an earlier SHA. Run @keboola-pr-reviewer-bot review to get a fresh verdict.
|
New commit on |
soustruh
left a comment
soustruh
left a comment
There was a problem hiding this comment.
Approved. Checked on a real project: for a failed job inside a flow, job detail --log-tail-lines 20 returned 0 events on 0.95.0 and 20 events on this branch, including the failure reason. CI is green.
3 participants
What
job detail --log-tail-lines Nand theservejob log stream now return events for nested jobs (jobs inside a flow, child row jobs of a row-based component). Before, they came back withlogTail: [].Why
A nested Queue job has a dotted
runId(<parent>.<child>.<job id>, e.g.56452146.56453149.56453151).GET /v2/storage/events?runId=<dotted>returns zero events, while the plain job id (56453151) returns the job's events. kbagent sentrunIdfirst and assumedrunId == id, which only holds for top-level jobs.How
resolve_events_run_id(job)inservices/job_service.py: the job's ownidfirst, else the last segment of a dottedrunId, else"". It keeps the defensive empty return when neither exists._safe_fetch_log_tailand by theserveSSE log stream (server/routers/jobs.py), the only two callers offetch_job_events.client.fetch_job_eventsis unchanged. It still sends the value as therunIdfilter. Its docstring now says to pass the job id and explains why.(since vNEXT), and the raw-API hint now says to query by job id.How tested
TestSafeFetchLogTailNestedJobs) cover four cases: dottedrunIdplusidfetches byid; only a dottedrunIduses its last segment; a top-level job withrunId == idis unchanged; neither key returns[]with no call.runId("702-run") that differs fromid. Their assertions now expect the job id.test_build_hookfails only because the local systemuvis older thanrequired-version, which is unrelated to this change.Fixes #787