Replies: 2 comments
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Resolved — root cause identified. This turned out to be a client-side issue, not a platform bug. The workflow file contained ~600 lines of inline JavaScript in Symptoms:
Fix: Extract large inline scripts to external Diagnostic shortcut: If the workflow name in Hope this saves someone else a few hours. Closing as resolved. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
The GitHub Actions workflow indexer appears stuck on a private repository. The workflow YAML is valid and present on the default branch, but GitHub does not recognize any of its triggers.
Symptoms
workflow_dispatchreturns HTTP 422 —Workflow does not have 'workflow_dispatch' triggerdespiteworkflow_dispatch:being present in the file.issues,issue_comment) do not fire — labeling an issue or posting a comment produces no workflow run.namein the REST API returns the file path instead of the YAMLname:value — indicating the file content was never fully parsed by the indexer.What we tried
workflow_dispatch: {}vs bareworkflow_dispatch:Diagnostic evidence
The
namefield returning the file path instead of the YAMLname:value is a reliable indicator that the indexer never parsed the file content.Timing
This began on 2026-03-12, coinciding with the "Actions failures to download (401 Unauthorized)" incident. Workflow file changes made during the degraded window appear to have been missed by the indexer, with no recovery after the incident resolved.
The same workflow was functioning correctly earlier the same day — all event triggers were firing and
workflow_dispatchworked.Expected behavior
The workflow indexer should parse the file content on push to the default branch, register all declared triggers, and reflect the YAML
name:value in the API.workflow_dispatchshould return 204 and event-based triggers should produce runs.Question
Is there a way to force the workflow indexer to re-parse a workflow file? Or is this a known issue during/after Actions incidents?
Beta Was this translation helpful? Give feedback.
All reactions