fix(ci): raise the capture job ceiling so long captures survive

[jensholdgaard]

Both corpus/otel-demo-v5 capture attempts (runs 27293201562, 27300579008) were cancelled at exactly 45m46s — the job's fixed timeout-minutes: 45, sized for the short default capture, kills any long window dispatched from main. The successful 4h v4 capture only survived because it was dispatched from feat/bench-scale-series, whose timeout bump (da1f41d) never merged.

Fix: a fixed timeout-minutes: 355 (just under GitHub's hard 6h job cap). A duration-scaled expression is NOT possible — GitHub Actions expressions have no arithmetic operators (caught by CodeRabbit), and 5h + headroom would exceed the 360m hosted cap anyway (caught by Copilot). On this rare, manual-dispatch-only workflow, a hung run burning toward the platform cap is the cheaper failure mode than another silently killed capture; the comment on the line records why it cannot scale.

Unblocks re-dispatching v5 (B2 corpus mass) and the flagged v6 (B1 error band, #172).

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

[jensholdgaard]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Walkthrough

The workflow job timeout for the OpenTelemetry demo corpus capture is made dynamic. Instead of a fixed 45-minute timeout, the timeout now scales proportionally with the requested capture duration (duration_seconds input) plus a 75-minute buffer, allowing longer capture windows to run without premature timeout failures.

Changes

Job Timeout Scaling

Layer / File(s)	Summary
Dynamic timeout based on capture duration .github/workflows/capture-otel-demo-corpus.yml	timeout-minutes is computed from inputs.duration_seconds converted to minutes plus a 75-minute buffer. Comments describing the timeout logic and the previously observed failure mode are updated accordingly.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Possibly related PRs

• jensholdgaard/ourios#73: Also modifies the same workflow's timeout behavior for the capture job, changing from fixed 45 minutes to a duration-based calculation with buffer.

Poem

A timeout that grows with the task at hand,
No more premature failures across the land! 🐰⏱️
Forty-five minutes? Too rigid and tight—
Now capture jobs run for the duration of night!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title describes scaling capture job timeout, which directly aligns with the main change to make timeout scale with duration_seconds instead of being fixed at 45 minutes.
Description check	✅ Passed	The PR description is comprehensive and addresses the problem, solution, and constraints. However, it lacks the checklist sections from the template (cargo fmt, clippy, tests, docs/CHANGELOG).

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/capture-timeout-scales

---

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 and usage tips.}

[Copilot]

Pull request overview

Adjusts the capture-otel-demo-corpus GitHub Actions workflow so long-running corpus captures don’t get terminated by an undersized fixed job timeout, aligning CI behavior with the workflow’s configurable capture window.

Changes:

• Replaces the fixed timeout-minutes: 45 with a computed timeout derived from inputs.duration_seconds.
• Updates the inline rationale comment to document why the timeout must scale with longer captures.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/capture-otel-demo-corpus.yml:
- Line 75: The timeout-minutes expression uses unsupported arithmetic; change to
compute the scaled timeout in a prior step (e.g., a step named compute-timeout)
that reads inputs.duration_seconds (default 600), computes timeout_minutes =
floor(duration_seconds/60) + 75, and exposes it as an output or env (use echo
"timeout_minutes=..." >> $GITHUB_OUTPUT or set-output equivalent). Then replace
the inline expression for timeout-minutes with the numeric output reference
(e.g., use ${{ steps.compute-timeout.outputs.timeout_minutes }}) so the job's
timeout-minutes receives a plain number.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 22c77ec9-cc66-4934-971e-0d5594a1e336

📥 Commits

Reviewing files that changed from the base of the PR and between 7dbaa07 and d6dd6e1.

📒 Files selected for processing (1)

• .github/workflows/capture-otel-demo-corpus.yml

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.