[Bug][github_graphql] `Collect Issues` fails on second phase with `Field 'requestedIssues' doesn't exist on type 'Query'`

[yamoyamoto]

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

1. Collect Data once so _tool_github_issues has rows for the scope.
2. Collect Data again — 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

[dosubot]

Thanks for the detailed bug report, @yamoyamoto! Your diagnosis is spot on.

Looking at the current main branch, the GraphqlQueryIssueDetailWrapper struct does not contain the requestedIssues field — it only has RateLimit and Repository. The tracking is done via a closure variable issueUpdatedAt (a map[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 problematic requestedIssues field? The v1.0.3-beta12 tag doesn't seem to exist in the repository — only v1.0.3-beta1 and v1.0.3-beta2 are 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 main should resolve it.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[yamoyamoto]

@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]

You're absolutely right, apologies for the confusion. I was indeed looking at the main branch (commit 2c15ad88) which corresponds to the older v1.0.3-beta2 lineage and doesn't have the stale-issue cleanup code from PR #8820.

I've now verified the actual v1.0.3-beta12 code at commit 1d21f199 and can confirm the bug: the unexported requestedIssues map[int]missingGithubIssueRef field is present on GraphqlQueryIssueDetailWrapper and merico-ai/graphql's writeQuery will serialize it as a top-level requestedIssues selection on Query, causing GitHub's API to reject it.

Your proposed fix is correct — moving requestedIssues out of the struct and into a closure-scoped variable (or onto GithubTaskData) would prevent it from being serialized into the GraphQL query. The BuildQuery closure already has access to reqData and can populate a map[int]missingGithubIssueRef in the enclosing scope, and the ResponseParser closure can read it back — exactly the same pattern already used for the issueUpdatedAt map on L162. Looking forward to your PR!

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.