### Summary A custom AI Catalog flow (`workflow_definition: ai_catalog_agent`) that contains a `HumanInputComponent` cannot pause for user input when executed in an ephemeral CI workload pipeline on GitLab.com. The moment the HumanInput `request` is emitted, the GitLab-managed CI executor (precompiled Duo CLI) treats the paused-workflow WebSocket close as an error, reconnects, sends a `RESPONSE` event with an empty message, is rejected by the server with code `4400`, and exits non-zero. Rails then marks the session `failed (dropped)` within seconds. The session never persists in `input_required`, so Approve / Reject / Modify in the Sessions UI are never actionable. Flows without a `HumanInputComponent` execute and finish normally in the same project with the same executor. ### Environment - GitLab.com (SaaS), 19.4.0 - Flow type: custom AI Catalog flow / agent, triggered by issue `@mention` - Execution: ephemeral CI workload pipeline (GitLab-managed executor, precompiled Duo CLI) - Project: https://gitlab.com/outbound-project/soc-5-outbound (work item #1 used as trigger surface) ### Steps to reproduce 1. Create a custom AI Catalog flow with: `Agent -> HumanInputComponent -> END` (any `interaction_type`; both `input` and `approval` reproduce). 2. Enable it in a project and trigger it via `@mention` on an issue. 3. Observe the session in `/-/automate/agent-sessions/<id>` and the CI workload job trace. ### Observed behavior Session event sequence (identical in all six failing sessions): 1. `Starting Flow: ...` 2. Agent message completes. 3. HumanInput `request` event emitted (`message_template` rendered, `on_user_input_prompt` logged). 4. `Error during Session: script_failure` 5. Session status `failed (dropped)` within ~5–40 seconds of the request event. CI workload job trace sequence: 1. WebSocket closed with code `1006` (abnormal closure) immediately after the HumanInput request is sent. 2. Executor reconnects. 3. Executor sends a `RESPONSE` event with an **empty** message. 4. Server rejects with close code `4400`: `RESPONSE event must include a non-empty message. The workflow remains paused; please provide real user input to continue.` 5. Executor exits non-zero -> CI job fails -> Rails marks the session `failed`. ### Sessions demonstrating the failure (all in the project above) Failing (HumanInputComponent present): - 7575514, 7575899 (diagnostic HumanInput integration test, `interaction_type: input`) - 7576675, 7576978 (minimal reproduction "Test 4A": `Agent -> HumanInput -> END`, `interaction_type: approval`) - 7573547, 7574073 (production flow "Engineering Implementation") Passing controls (no HumanInputComponent, same project, same executor): - 7574487 (single agent), 7574877 (2-agent chain), 7575149 (3-agent chain) -> all `finished` Last recorded event in session 7576978 (via session context API): ``` request | 2026-09-12T03:19:23.274609+00:00 Test 4A HumanInput checkpoint. The diagnostic agent has completed successfully. Review this checkpoint and choose: - Approve: finish the test successfully - Modify: send feedback back to the diagnostic agent - Reject: stop the test ``` followed by `summary: "Error during Session: script_failure"`, `status: failed`. ### Ruled out - Flow YAML schema (validates; agent-only variants of the same YAML finish successfully) - `interaction_type` (`input` and `approval` both fail) - `ui_log_events` configuration - `sends_response_to` KeyError (only reachable after a human actually responds, which never happens here) - `.gitlab/duo/agent-config.yml` (not present; supported keys cannot pin executor version anyway) - Application code in the target repository (untouched, read-only prompts) ### Expected behavior - When the workflow reaches a `HumanInputComponent`, the executor should exit `0` (or otherwise signal a clean pause) on `INPUT_REQUIRED` instead of treating the socket close as an error. - The executor must not synthesize and send an empty `RESPONSE` event on reconnect. - The session should persist in `input_required` until the user responds (Approve / Reject / Modify) in the Sessions UI, after which a new workload resumes the flow. ### Impact Any CI-executed custom flow that includes a human approval gate is unusable on GitLab.com 19.4. Teams must either remove the gate or split flows into separate plan-only and implement flows, which defeats the purpose of `HumanInputComponent`. ### Additional evidence pending The workload pipeline is deleted seconds after the job fails; a captured job trace (Duo CLI / executor version line, 1006 close, reconnect, empty RESPONSE, 4400 rejection) will be attached as soon as it can be exported before deletion. Please advise if a support ticket or session IDs on the backend are sufficient for the Duo Workflow team to pull the trace.