@csantarin as the error says its most likely a timeout due to the complexity and amount of data involved in the query.
If the exact same query works with an example involving less data that would also indicate that as the most likely cause.

@byrneh You’re likely on to something.

Our discussion body field looks something like this:

          body: |
            "# Note\n
            **To cherry-pick a bug fix to the release branch, kindly comment the PR merge commit hash in this discussion thread.**\n\n
            | ✅ Do this! | ❌ ...and not this. |\n
            | --- | --- |\n
            | ![image](https://user-images.githubusercontent.com/[SOME_NUMBER]/[uuid].png) | ![image](https://user-images.githubusercontent.com/[SOME_NUMBER]/[uuid].png) |\n
            # Pull Requests\n"
            ${{ env.DISCUSSION_BODY }}"
      title: "${{ github.event.inputs.rc_version_name }}"

And this env.DISCUSSION_BODY was implemented in a previous step which is pulls all of the changes between two release versions:

          BODY=$(git log origin/release/$PREV_RC_VERSION..origin/release/$RC_VERSION  --pretty=tformat:"%h %s\n" --merges --grep="pull request");
          echo 'DISCUSSION_BODY<<EOF' >> $GITHUB_ENV
          echo "$BODY" >> $GITHUB_ENV
          echo 'EOF' >> $GITHUB_ENV

This list alone amounted to near 250 lines for us at the time. Normally, it has been far less than that (some 150, definitely below 200).

After removing ${{ env.DISCUSSION_BODY }} from the body input, the workflow succeeded. There was no timeout.

Is there a known and documented limit to the createDiscussion API method (or just about any GitHub GraphAAQL API method at all)? That will help us understand the limitations better.

When using queries that are at risk of timeout I tune my query to retrieving smaller set of data and leverage paging.

Pagination, eh? We’ll definitely have a look at that…

My only concern now is how to chain it until all parts of the expected final body have been added to the created discussion.

Perhaps breaking the absurdly large body value off from the createDiscussion call and add a new step with updateDiscussion can sort of handle this at the side. We only need the ID from the createDiscussion results, anyway. The main content of the discussion can be put afterwards with no need to acknowledge the response… is my take.

GitHub support confirming the replies here so far:

Indeed, we sent a query body that was too long for the API to return a response on time (limit: 10 seconds). The request waiting time exceeded this limit. As a consequence, we experienced a timeout.

We need to break it down into smaller requests.

I see this error when using postman or locally trying to make graphql queries against GitHub, but not when using the Github graphql explorer:

"message": "Something went wrong while executing your query. This may be the result of a timeout, or it could be a GitHub bug. Please include `4A9B:716A:296B9:53EA6:64DCF39F` when reporting this issue."