@copilot add-comment in a discussion should be a threaded comment reply rather than a top level discussion reply.
Originally posted by @pelikhan in #23753
PR #23836 added auto-threading for add_comment when triggered by discussion_comment: it derives replyToId from context.payload.comment.node_id. This works perfectly when the triggering comment is a top-level Discussion comment.
In our case, the triggering comment is itself a threaded reply (Level 1). The handler passes the reply's node_id as replyToId, and GitHub's API returns:
"Parent comment is already in a thread, cannot reply to it"
GitHub Discussions only supports two levels: top-level comments and one level of replies. replyToId must point to a top-level comment.
We tried patching GITHUB_EVENT_PATH in a pre-step to swap the comment.node_id to the parent, but pre-steps run in the agent job while add_comment executes in the safe_outputs job — which gets its own unpatched copy of the event payload.
Originally posted by @pelikhan in #23753
PR #23836 added auto-threading for add_comment when triggered by discussion_comment: it derives replyToId from context.payload.comment.node_id. This works perfectly when the triggering comment is a top-level Discussion comment.
In our case, the triggering comment is itself a threaded reply (Level 1). The handler passes the reply's node_id as replyToId, and GitHub's API returns:
"Parent comment is already in a thread, cannot reply to it"
GitHub Discussions only supports two levels: top-level comments and one level of replies. replyToId must point to a top-level comment.
We tried patching GITHUB_EVENT_PATH in a pre-step to swap the comment.node_id to the parent, but pre-steps run in the agent job while add_comment executes in the safe_outputs job — which gets its own unpatched copy of the event payload.