Repository navigation
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot merge main fix conflicts |
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
…tions-job-agent # Conflicts: # actions/setup/js/start_mcp_gateway.test.cjs Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Merged |
|
✅ Ponytail Reviewer completed successfully!
|
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅
|
|
✅ Design Decision Gate 🏗️ completed the design decision gate check. See the comment below for the result and any generated ADR draft. Design Decision Gate 🏗️Outcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
|
✅ PR Code Quality Reviewer completed the code quality review.
|
|
✅ Test Quality Sentinel completed test quality analysis. Test Quality SentinelOutcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
There was a problem hiding this comment.
L83-90: delete: default-parameter coverage unrelated to the serialization-order fix. Existing explicit-identity and source-order tests cover this change; nothing replaces it.
net: -8 lines possible.
Generated by ✂️ Ponytail Reviewer for #69046 · codex · gpt56 · 8.03 AIC · ⌖ 5.31 AIC · ⊞ 14.6K
Comment /ponytail to run again
| expect(backend).toEqual({ container: "alpine:3.24", args: ["--user", "1001:123"], env: { HOME: "/custom" } }); | ||
| }); | ||
|
|
||
| it("defaults to the current runner identity", () => { |
There was a problem hiding this comment.
L83-90: delete: default-parameter coverage unrelated to the serialization-order fix. Existing explicit-identity and source-order tests cover this change; nothing replaces it.
There was a problem hiding this comment.
The call-order change is reverted in 24aeab6. I kept the default-identity test as focused coverage for the existing runner-identity behavior, not as coverage for serialization ordering.
|
@copilot fix ci failures |
Comment MemoryPeek at saved memory (pr-code-quality-reviewer)Note This comment is managed by comment memory.Expand the saved memory block to view or edit the persistent context for this thread.
|
There was a problem hiding this comment.
Blocking
This PR doesn't appear to fix the failing agent path yet: the reordered call only changes a dead serialization step, while the gateway still starts from the live configObj later in the file.
Themes
- The runtime behavior is still driven by
JSON.stringify(configObj)at process launch, so the timeout-order change here is effectively a no-op. - The added test covers default UID/GID injection, but not the launch path that actually broke, so the regression can slip back in unnoticed.
🔎 Code quality review by PR Code Quality Reviewer · copilot · gpt54 · 54.2 AIC · ⌖ 5.66 AIC · ⊞ 20.2K
Comment /review to run again
| return; | ||
| } | ||
| applyAgenticWorkflowsRunnerIdentity(configObj); | ||
| applyGatewayRuntimeTimeouts(configObj, process.env); |
There was a problem hiding this comment.
Reordering these calls still leaves the runtime behavior unchanged, because the gateway is launched from JSON.stringify(configObj) later in the file instead of the mcpConfig string you mutate here.
💡 Why this blocks the fix
The only thing this hunk changes is the order before mcpConfig = JSON.stringify(configObj), but mcpConfig is never used to start the child process after that point. A few lines later we write JSON.stringify(configObj) directly to child.stdin, so this PR does not actually change what the gateway receives at runtime and the original agent failure can still reproduce.
Please either remove the dead mcpConfig state and serialize from a single source of truth, or move the fix to the code path that actually writes the config into the gateway process, then add a regression test around that live path.
There was a problem hiding this comment.
Agreed; the reordered call was a no-op for the live launch path. I reverted it in 24aeab6 and am no longer claiming it fixes gateway serialization.
| expect(backend).toEqual({ container: "alpine:3.24", args: ["--user", "1001:123"], env: { HOME: "/custom" } }); | ||
| }); | ||
|
|
||
| it("defaults to the current runner identity", () => { |
There was a problem hiding this comment.
This new test doesn't cover the regression the PR is supposed to fix, so we still have no test that would fail if the timeout mutation is serialized on the wrong code path again.
💡 Why the current coverage is insufficient
The behavioral change in this PR is the attempted timeout-order fix in main(), but the added test only exercises the default UID/GID branch in applyAgenticWorkflowsRunnerIdentity(). The existing ordering assertion also keys off the dead mcpConfig = JSON.stringify(configObj) assignment, which can keep passing even when the configuration actually sent to child.stdin is still wrong.
Please add a regression test around the live launch path — for example, assert that the object written into the spawned gateway process contains the updated gateway timeout values.
There was a problem hiding this comment.
Agreed; the test does not cover the live serialization path. The no-op reorder is reverted in 24aeab6, and this PR is being treated as additional coverage for the existing runner-identity behavior.
There was a problem hiding this comment.
🟡 Changes recommended
The reorder does not implement the claimed failure fix; the existing identity fix should be acknowledged and this PR re-scoped as test coverage.
1 open finding
What changed in this PR
This PR targets the failing agent job through MCP gateway startup and backend identity coverage.
Changes:
- Tests default runner UID/GID and
HOME=/tmp. - Reorders timeout and identity setup without changing behavior.
| File | Description |
|---|---|
actions/setup/js/start_mcp_gateway.test.cjs |
Adds default backend identity coverage. |
actions/setup/js/start_mcp_gateway.cjs |
Reorders gateway preparation calls. |
🧠 Review effort: Max
There was a problem hiding this comment.
Skills-Based Review 🧠
Applied /diagnosing-bugs and /tdd — requesting changes: the proposed fix doesn't appear to address the actual failure, and the new test doesn't guard the claimed fix.
📋 Key Themes & Highlights
Key Themes
- Unverified root cause:
applyGatewayRuntimeTimeoutsandapplyAgenticWorkflowsRunnerIdentitymutate disjoint parts ofconfigObj(gateway.*vsmcpServers.agenticworkflows.*); reordering them produces identical output in local testing. The PR body doesn't link the actual error/stack trace from job run 38681249689, so it's unclear this change fixes anything. - Test doesn't cover the fix: the added test calls
applyAgenticWorkflowsRunnerIdentityin isolation and would pass unchanged regardless of call order inmain(). It doesn't demonstrate red-before/green-after for this specific bug. - PR still marked [WIP]: title/body suggest work in progress; confirm intent before merge.
Positive Highlights
- ✅ Small, surgical diff — easy to review in isolation
- ✅ Attempted to add test coverage alongside the behavior change, which is good practice even if the test needs refinement
@copilot please address the review comments above.
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · copilot · sonnet50 · 94.6 AIC · ⌖ 14.9 AIC · ⊞ 11.7K
Comment /matt to run again
| } | ||
| applyAgenticWorkflowsRunnerIdentity(configObj); | ||
| applyGatewayRuntimeTimeouts(configObj, process.env); | ||
| applyAgenticWorkflowsRunnerIdentity(configObj); |
There was a problem hiding this comment.
[/diagnosing-bugs] This reorder may be treating a symptom, not the root cause: applyGatewayRuntimeTimeouts only touches config.gateway.*/env.*, and applyAgenticWorkflowsRunnerIdentity only touches config.mcpServers.agenticworkflows.* — they mutate disjoint fields with no shared state, so swapping their call order produces a byte-identical configObj either way (verified locally). If that's correct, this change doesn't explain why job 'agent' (run 38681249689) failed, and the real root cause is still unaddressed.
💡 Verification
// Both orders produce identical output:
applyAgenticWorkflowsRunnerIdentity(configA, 1001, 123);
applyGatewayRuntimeTimeouts(configA, env);
// vs
applyGatewayRuntimeTimeouts(configB, env);
applyAgenticWorkflowsRunnerIdentity(configB, 1001, 123);
// JSON.stringify(configA) === JSON.stringify(configB) -> trueBefore merging, please link the actual failure log/stack trace from the referenced job run and confirm this reorder is what fixes it — otherwise the PR may close out as a false fix for a still-open CI failure.
@copilot please address this.
There was a problem hiding this comment.
The referenced job log identifies the failure at secret redaction: artifact-source read and unlink returned EACCES, and write returned EPERM; the step then failed closed. The reorder did not address that, so it is reverted in 24aeab6; the runner-identity fix is already in the base.
| const uid = process.getuid?.(); | ||
| const gid = process.getgid?.(); | ||
| applyAgenticWorkflowsRunnerIdentity({ mcpServers: { agenticworkflows: backend } }); | ||
| expect(backend.args).toEqual(["--user", `${uid}:${gid}`]); |
There was a problem hiding this comment.
[/tdd] This new test doesn't exercise the actual fix. It calls applyAgenticWorkflowsRunnerIdentity directly and would pass identically whether or not the call-order swap in main() is present — it isn't a regression test for this PR's change and wouldn't have failed on the pre-fix code.
💡 Suggested approach
Per red-green-refactor: write a test that fails against the old ordering and passes with the new one — e.g. assert on the sequence of mutations applied to a shared configObj passed through main()'s validation path, or spy on both functions and assert call order. As written, this test only duplicates coverage of applyAgenticWorkflowsRunnerIdentity's default-identity behavior (already partially covered by other cases in this file) and gives false confidence that the ordering bug is now guarded against.
@copilot please address this.
There was a problem hiding this comment.
Agreed; this test would not catch a call-order regression. The no-op reorder is reverted in 24aeab6, and the retained test only covers the existing default runner-identity behavior.
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Fixed the three failing agent-execution tests by using structured proxy error records. The impacted JS tests pass. Commit: |
|
@copilot run pr-finisher skill |
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Ran the PR finisher. Commit |
|
@copilot address the following outstanding work in one pass:
Push the necessary fixes, reply to each listed review thread and resolve it when addressed. Ignore feedback already answered or resolved. Use the pr-finisher skill and stop when only human review or CI remains; do not trigger CI. Sous-chef head: 24aeab6
|
…tions-job-agent # Conflicts: # actions/setup/js/agent_execution.test.cjs Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
Merged latest |

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.