Fix error messages not shown in gh aw compile output#14901
Conversation
Previously, when running `gh aw compile`, users would only see the count of errors and the workflow filenames, but not the actual error messages. They had to use `--json` flag or set `DEBUG` environment variable to see what went wrong. This change: - Adds ErrorMessages field to WorkflowFailure struct - Updates trackWorkflowFailure to pass error messages - Updates printCompilationSummary to display actual error messages Fixes: Error messages are now shown in the compilation summary without requiring DEBUG env var or --json flag. Co-authored-by: eaftan <4733401+eaftan@users.noreply.github.com>
- Added comment clarifying that only first error is used for return value - Added comment noting error messages include workflow path in file:line:col format Co-authored-by: eaftan <4733401+eaftan@users.noreply.github.com>
🔍 PR Triage ResultsCategory: bug | Risk: low | Priority: 50/100 Scores Breakdown
📋 Recommended Action: deferRationale: Draft PR marked [WIP] - not ready for review until author marks ready for review. Next Steps:
Triaged by PR Triage Agent on 2026-02-11
|
There was a problem hiding this comment.
Pull request overview
This PR ensures gh aw compile surfaces the underlying validation/resolution error messages to users instead of only reporting counts and file paths.
Changes:
- Add
ErrorMessages []stringtoWorkflowFailureand plumb messages through compilation orchestration. - Update
trackWorkflowFailureto store per-workflow error messages. - Update
printCompilationSummaryto print stored error messages in the error summary output.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| pkg/cli/compile_orchestration.go | Collects validation error messages and passes them into failure tracking. |
| pkg/cli/compile_helpers.go | Extends failure tracking and updates summary printing to show error messages. |
| pkg/cli/compile_config.go | Adds ErrorMessages field to WorkflowFailure. |
| pkg/cli/compile_command_test.go | Updates tests to validate storing/propagating error messages in tracked failures. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| for _, errMsg := range failure.ErrorMessages { | ||
| fmt.Fprintln(os.Stderr, errMsg) |
There was a problem hiding this comment.
printCompilationSummary will print nothing for failures that have FailureDetails entries but an empty ErrorMessages slice (e.g., if validation produced zero messages or a caller passes nil/empty). Since the else if len(stats.FailedWorkflows) > 0 fallback won’t run when FailureDetails is non-empty, users can lose all indication of which workflows failed. Add an in-loop fallback when len(failure.ErrorMessages)==0 (e.g., print failure.Path and failure.ErrorCount, or a generic “failed workflow” line) so failures are still visible even without messages.
| for _, errMsg := range failure.ErrorMessages { | |
| fmt.Fprintln(os.Stderr, errMsg) | |
| if len(failure.ErrorMessages) > 0 { | |
| for _, errMsg := range failure.ErrorMessages { | |
| fmt.Fprintln(os.Stderr, errMsg) | |
| } | |
| } else { | |
| // Fallback when there are no individual error messages for this failure | |
| if failure.Path != "" { | |
| fmt.Fprintln( | |
| os.Stderr, | |
| console.FormatErrorMessage( | |
| fmt.Sprintf("Failed workflow %s (%d error(s))", failure.Path, failure.ErrorCount), | |
| ), | |
| ) | |
| } else { | |
| fmt.Fprintln( | |
| os.Stderr, | |
| console.FormatErrorMessage( | |
| fmt.Sprintf("Failed workflow (%d error(s))", failure.ErrorCount), | |
| ), | |
| ) | |
| } |
| fmt.Fprintln(os.Stderr, console.FormatErrorMessage(summary)) | ||
| // List the failed workflows with their error counts | ||
| // Display actual error messages from each failed workflow | ||
| // Error messages already include workflow path in format: file:line:col: error: message |
There was a problem hiding this comment.
The comment asserts error messages “already include workflow path…”, but at least one caller passes err.Error() directly (e.g., resolution errors), which may not include the workflow path/line/col. Either (a) adjust the comment to reflect that messages may be raw, or (b) ensure call sites consistently prefix messages with workflowPath (and location when available) before storing/printing.
| // Error messages already include workflow path in format: file:line:col: error: message | |
| // Error messages may already include workflow path/position (e.g., "file:line:col: error: message"). | |
| // Callers are responsible for adding path/position context when available. |
| // Collect error messages from validation result for display in summary | ||
| var errMsgs []string | ||
| for _, verr := range fileResult.validationResult.Errors { | ||
| errMsgs = append(errMsgs, verr.Message) | ||
| } | ||
| trackWorkflowFailure(stats, resolvedFile, 1, errMsgs) |
There was a problem hiding this comment.
The “collect error messages from validation result” loop is duplicated (also in compileAllFilesInDirectory). Consider extracting a small helper (e.g., collectValidationMessages(errors []CompileValidationError) []string) to avoid repetition and keep message selection rules consistent in one place.
| // Collect error messages from validation result | ||
| var errMsgs []string | ||
| for _, verr := range fileResult.validationResult.Errors { | ||
| errMsgs = append(errMsgs, verr.Message) | ||
| } | ||
| trackWorkflowFailure(stats, file, 1, errMsgs) |
There was a problem hiding this comment.
Same duplication as above—prefer reusing a shared helper for collecting verr.Message so future changes (filtering, formatting, truncation) don’t require editing multiple compilation paths.
|
|
||
| // trackWorkflowFailure adds a workflow failure to the compilation statistics | ||
| func trackWorkflowFailure(stats *CompilationStats, workflowPath string, errorCount int) { | ||
| func trackWorkflowFailure(stats *CompilationStats, workflowPath string, errorCount int, errorMessages []string) { |
There was a problem hiding this comment.
Consider making errorMessages variadic (errorMessages ...string) instead of []string. This makes call sites clearer for the common single-message case and avoids forcing callers to allocate slices like []string{err.Error()} just to pass one message.
Error messages from
gh aw compilewere not displayed to users—only error counts and file paths were shown. Users had to setDEBUG=workflowor use--jsonto see what actually went wrong.Changes
ErrorMessages []stringfield toWorkflowFailurestructtrackWorkflowFailurefrom compile orchestrationprintCompilationSummaryBefore
After
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.