Fix safe output handlers returning { success: false } incorrectly marked as successful and GraphQL query error in project status updates

[Copilot]

Safe output handlers that catch exceptions and return { success: false, error: "..." } were incorrectly logged as successful. The handler manager only caught thrown exceptions, missing the explicit failure signal in the return value.

Additionally, the GraphQL query for listing projects was causing API errors due to requesting redundant fields.

From workflow run #20901743240:

Creating status update for project: https://github.com/orgs/githubnext/projects/73
✗ Failed to create project status update: GraphQL query failed
✓ Message 16 (create_project_status_update) completed successfully  ← Wrong

Changes

Handler manager (safe_output_handler_manager.cjs)

• Added explicit check for result.success === false after handler invocation
• Applied in both main processing loop and deferred retry loop
• Skip success logic and record error when detected

const result = await messageHandler(message, resolvedTemporaryIds);

if (result && result.success === false && !result.deferred) {
  const errorMsg = result.error || "Handler returned success: false";
  core.error(`✗ Message ${i + 1} (${messageType}) failed: ${errorMsg}`);
  results.push({ type: messageType, messageIndex: i, success: false, error: errorMsg });
  continue;
}

Project status update handler (create_project_status_update.cjs)

• Fixed listAccessibleProjectsV2 GraphQL query to use only nodes field instead of both nodes and edges
• Removed redundant field that was causing "Something went wrong while executing your query" API errors
• Simplified node processing logic

Test coverage (safe_output_handler_manager.test.cjs)

• Added test case verifying handlers returning { success: false } are treated as failures

Impact

Handler Manager Fix: Affects all handlers using the error-catching pattern (~20+ handlers):

• create_project_status_update, create_issue, add_comment, add_labels, add_reviewer, assign_milestone, close_issue, close_pull_request, create_code_scanning_alert, dispatch_workflow, hide_comment, link_sub_issue, update_issue, update_discussion, update_pull_request, and others

GraphQL Query Fix: Eliminates API errors when falling back to list-based project resolution, making project status updates more reliable

Original prompt

See run: https://github.com/githubnext/gh-aw/actions/runs/20901743240
We see the agent called:
Analyze failing ✓ safeoutputs-update_project
└ {"content":[{"text":"{"result":"success"}","type":"text"}]}
But the project status update never happens.
safe_outputs
Failed to create project status update: Request failed due to following response errors:

• Something went wrong while executing your query on 2026-01-11T21:14:46Z. Please include 1830:81121:56BF94:175C13D:696412C6 when reporting this issue.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[mnkiefer]

@copilot Also fix underlying issue for failing project status update.

[Copilot]

@copilot Also fix underlying issue for failing project status update.

Fixed in 0f54983. The underlying issue was that the GraphQL query in listAccessibleProjectsV2 was requesting both nodes and edges fields, which was causing API errors. Simplified the query to use only the nodes field, which is the standard pattern for non-paginated queries.