Strange Behavior When Triggering Reusable Workflows via API — 404 “suffixed values” Error

[PuneetDwivediDnb]

Select Topic Area

Bug

Body

We’re experiencing a strange regression with GitHub Actions related to reusable workflows and dispatching workflows via the API or gh CLI.

Setup

In the same repository, we have:

Workflow A

A reusable workflow triggered using workflow_call:

name: Workflow A
on:
  workflow_call:

jobs
   // some job goes here

Workflow B

A workflow triggered using workflow_dispatch that reuses Workflow A:

name: Workflow B
on:
  workflow_dispatch:

jobs:
  workflowA:
    uses: ./.github/workflows/workflowA.yml

The above setup is logically correct, and everything works as expected when triggered from the GitHub UI. This is our happy-path scenario for us.

Issue

In above setup, When we trigger Workflow Busing the GitHub API or the gh CLI, the workflow starts successfully and its run appears in the GitHub UI. However, when we try to retrieve that API‑triggered run using the GitHub API or gh CLI, we receive the following response

Response 404
{"message":"Unable to complete request that contains suffixed values in the response payloads."}

The difficult part is that the same setup was working perfectly until about a week ago or so.

Observations

When we replace the relative reference to Workflow A with an absolute reference in Workflow B, the issue disappears.
For ex:

name: Workflow B
on:
  workflow_dispatch:

jobs:
  workflowA:
    uses: owner/repo/.github/workflows/workflowA.yml@ref          # changed here to full import

Making above change start everything work as expected.

We recently observed this behaviour, and we have similar pattern across repos and orgs. We have use github api and cli in upstream & downstream pattern. Want to understand what is changed and why issue arises, as this all started breaking in a while.
To put some more context this behaviour is observed in enterprise version(*.ghe.com) of github. Thanks in advance....

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Tsknefe]

This usually happens when the workflow being triggered through the API cannot be resolved correctly by GitHub Actions.
When dealing with reusable workflows (workflow_call), there are a few subtle behaviors that can lead to 404 responses.

Some common causes:

1. Wrong workflow identifier:

The API expects either the workflow file name or the workflow ID, not the name: field defined inside the YAML.
Example:
.github/workflows/workflow_a.yml
Then the dispatch endpoint should reference:
workflow_a.yml
not Workflow A.

2. Workflow not present on the target ref:

The workflow file must exist on the branch specified in the API request (ref).
If the file only exists on another branch, GitHub will return a 404.

3. Reusable workflows cannot be dispatched directly:

Workflows that only define:
on:
workflow_call:
are meant to be triggered by another workflow, not directly through the REST API.

If you need API-triggered execution, the parent workflow should include:
on:
workflow_dispatch:
and then call the reusable workflow internally.

4. Repository path resolution

The reusable workflow must be referenced using the correct path:
owner/repo/.github/workflows/workflow.yml@ref
If the API dispatch references a different ref or commit, GitHub may fail to resolve it.
In practice, the most stable pattern is:
API → workflow_dispatch → parent workflow → workflow_call reusable workflow
This keeps the API trigger separate from the reusable workflow logic.

[PuneetDwivediDnb]

To put some more : This whole setup is in *.ghe.com.
A similar setup was working until a few weeks ago (around 2–3 weeks back). But recently, the entire setup started failing without any changes on our side. These issues only became apparent after some investigation and observations.

[Tsknefe]

If this was working a few weeks ago and nothing changed on your side, it might indicate a regression on the GitHub Enterprise side. Especially since the setup is on *.ghe.com, the API dispatcher might be resolving reusable workflow paths differently than the UI. It could be worth checking the current GHES version or recent platform updates.

[jeffwilcox]

I'm seeing this same error message with other GraphQL calls in *.ghe.com...

[bukowskiadam]

Hey, I am here, because it's not the first time I struggle with this weird error response from ghe.com instance.

"Unable to complete request that contains suffixed values in the response payloads."

In the past I was able to change my tool to use graphql API, but this time it blocks my release-please execution, because it can't retrieve one of the commits in the history.

So to simplify this - I get an error when I try to fetch commit details through REST API like

gh api --hostname <my instance>.ghe.com repos/<owner>/<repo>/commits/<commit hash>

What does this error even mean?

[PuneetDwivediDnb]

Good to report it to your platform team, at your end. They did the job in our case to get it fix.