Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix: daily ET guardrail step never fails activation job; improve conclusion reporting #36497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: daily ET guardrail step never fails activation job; improve conclusion reporting #36497
Changes from all commits
cdccaf77d036225b875352884717f7e508bFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/diagnose] The outer
catchtreats all errors — including permanent ones like missing permissions or misconfigured tokens — the same as transient network blips. A persistent configuration error will silently bypass the guardrail on every run, with only acore.warningin the job log as the signal.💡 Suggestion
The current design is explicitly documented as intentional (safe bypass > broken activation), so this is not a blocker. However, consider adding a
core.error()call alongside the warning for non-retryable error classes, or emitting acore.summaryline so the bypass is visible in the Actions run summary rather than only in the raw log:This preserves the safe-bypass contract while making a stuck guardrail discoverable without digging into logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Silent bypass is indistinguishable from a clean pass in workflow outputs. When the catch fires,
daily_effective_workflow_exceededstays at"false"— the same value it has when the guardrail genuinely evaluated to "not exceeded". Any downstream observability (dashboards, audits) that reads this output cannot tell whether the guardrail passed or failed silently. The only signal is a transient::warning::in the step log that is easily missed.💡 Suggested improvement
Consider adding a dedicated output that makes the skip explicit:
Downstream steps and dashboards can then distinguish three states:
exceeded=true→ guardrail fired, block the agentexceeded=false, guardrail_error=false→ evaluated cleanly, under budgetexceeded=false, guardrail_error=true→ evaluation failed, agent allowed as safe fallbackThis is especially important for post-incident cost audits where "did the guardrail skip silently?" is a key question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incomplete
mockCorestub may cause vacuously-passing tests.mockCoreis missingerror,debug, andnoticemethods. If any production code path inside thetryblock calls one of them, theTypeError: core.xxx is not a functionwill be caught by the outer catch and produce a warning like"Daily workflow ET guardrail encountered an unexpected error and will be skipped: core.error is not a function"— which matches the regex/unexpected error.*skipped/i. The test then passes while hiding the actual regression.💡 Suggested fix
Add no-op stubs for the missing methods:
This ensures that any accidental call to these methods causes a type-safe no-op rather than a silently-caught TypeError that fools the regex assertion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] Assertions inside the
tryblock mean that if the firstexpectthrows, later assertions are silently skipped, reducing test confidence.💡 Suggested refactor
Move the
await expect(...)call outside the try/finally (or keep the try/finally only for cleanup), so Jest sees all assertion failures independently:This way all three assertions are always evaluated regardless of which one fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Global state deleted rather than restored — fragile isolation.
delete global.corepermanently removes the property rather than restoring whatever was there before. If a futurebeforeEachor test-helper ever pre-populates these globals, thisfinallyblock will silently trash them for subsequent tests, causing confusing cross-test contamination.💡 Suggested fix
Save and restore:
Alternatively, use
afterEachfor cleanup so Vitest handles the lifecycle correctly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] The refactor wraps the entire success path in the outer
try/catchtoo, but there's no regression test verifying that a normal execution where the threshold is exceeded still setsdaily_effective_workflow_exceededto"true". A logic bug inside thetryblock (e.g., an earlyreturnor swallowed error) could silently prevent the output from being set without any test catching it.💡 What to add
Add a companion test that mocks a successful API response returning runs whose total ET exceeds the threshold, and asserts:
This guards against the outer
catchaccidentally consuming an exception that would have set the output.Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.