Repository navigation
[Bug][github_graphql] Collect Issues fails on second phase with Field 'requestedIssues' doesn't exist on type 'Query' #8853
Description
Search before asking
- I had searched in the issues and found no similar issues.
What happened
In v1.0.3-beta12 the second phase of github_graphql Collect Issues (the stale-local-issue cleanup added in #8820) aborts the subtask with Field 'requestedIssues' doesn't exist on type 'Query':
[Collect Issues] ended Graphql collector execution with error
Wraps: (2) Field 'requestedIssues' doesn't exist on type 'Query'
Error types: (1) *hintdetail.withDetail (2) graphql.DataError
The unexported requestedIssues field added to GraphqlQueryIssueDetailWrapper in #8820 (issue_collector.go L54-L62) is intended as Go-side per-request metadata — populated before the request (L198) and read in the response callback (L221, L231) to detect issues that disappeared upstream. The merico-ai/graphql marshaller appears not to skip unexported fields, so requestedIssues is emitted as a top-level selection on Query and GitHub rejects it.
What do you expect to happen
Collect Issues completes both phases when _tool_github_issues already has rows.
How to reproduce
Collect Dataonce so_tool_github_issueshas rows for the scope.Collect Dataagain — phase 2 fails on the first request.
A scope with an empty _tool_github_issues skips phase 2 and does not surface the bug.
Anything else
The right fix is to move requestedIssues out of GraphqlQueryIssueDetailWrapper and keep it on the closure or on GithubTaskData. merico-ai/graphql's writeQuery (query.go L111-L173) does not special-case graphql:"-" (the tag value would just be rendered as the field name -) and does not skip unexported fields, so there is no struct-tag-only escape hatch on the wrapper as written.
Version
v1.0.3-beta12
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
dosubot commentedon Apr 26, 2026
Thanks for the detailed bug report, @yamoyamoto! Your diagnosis is spot on.
Looking at the current
mainbranch, theGraphqlQueryIssueDetailWrapperstruct does not contain therequestedIssuesfield — it only hasRateLimitandRepository. The tracking is done via a closure variableissueUpdatedAt(amap[int]time.Time) declared at L162, populated in the BuildQuery closure, and read in the ResponseParser closure.So it appears the approach you recommended (moving the metadata out of the struct and into the closure) is already how the code looks on
main. Could you double-check whether the version you're running actually contains the problematicrequestedIssuesfield? Thev1.0.3-beta12tag doesn't seem to exist in the repository — onlyv1.0.3-beta1andv1.0.3-beta2are present. It's possible you're running from a branch or build that includes the intermediate state from PR #8820 before it was corrected.If you're still hitting this on a specific build, upgrading to the latest
mainshould resolve it.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
yamoyamoto commentedon Apr 26, 2026
@dosu
This looks like it's checking an older commit. On the current v1.0.3-beta12 tag, requestedIssues is still a field on GraphqlQueryIssueDetailWrapper and is populated/read by the second Collect Issues pass, so the GraphQL error from the report still reproduces there. The 2c15ad8 commit referenced earlier sits on the v1.0.3-beta2 lineage.
dosubot commentedon Apr 26, 2026
You're absolutely right, apologies for the confusion. I was indeed looking at the
mainbranch (commit2c15ad88) which corresponds to the olderv1.0.3-beta2lineage and doesn't have the stale-issue cleanup code from PR #8820.I've now verified the actual
v1.0.3-beta12code at commit1d21f199and can confirm the bug: the unexportedrequestedIssues map[int]missingGithubIssueReffield is present onGraphqlQueryIssueDetailWrapperandmerico-ai/graphql'swriteQuerywill serialize it as a top-levelrequestedIssuesselection onQuery, causing GitHub's API to reject it.Your proposed fix is correct — moving
requestedIssuesout of the struct and into a closure-scoped variable (or ontoGithubTaskData) would prevent it from being serialized into the GraphQL query. TheBuildQueryclosure already has access toreqDataand can populate amap[int]missingGithubIssueRefin the enclosing scope, and theResponseParserclosure can read it back — exactly the same pattern already used for theissueUpdatedAtmap on L162. Looking forward to your PR!To reply, just mention @dosu.
Docs are dead. Just use Dosu.