fix: restore label validation to prevent gh issue create failures - #1346
Conversation
Closes #1342 When creating GitHub issues with gh CLI, attempting to apply a non-existent label causes the entire command to fail, wasting cycles and tokens. This restores defensive label validation that was removed in commit 9fd1b3a. The procedure now: 1. Explicitly instructs to fetch available labels via `gh label list` 2. Cross-checks selected labels against the fetched list 3. Only applies labels that exist in the repository This follows the same pattern already working in .github/workflow-prompts/issue-triage.md (line 19). Principle: tracer-bullets (get it working first) Principle: subtraction-creates-value (minimal fix, 1-2 lines per issue)
|
⏳ Code review in progress. Analyzing for code quality issues and best practices. Detailed findings will be posted upon completion. Using Amazon Q Developer for GitHubAmazon Q Developer1 is an AI-powered assistant that integrates directly into your GitHub workflow, enhancing your development process with intelligent features for code development, review, and transformation. Slash Commands
FeaturesAgentic Chat Code Review CustomizationYou can create project-specific rules for Amazon Q Developer to follow:
Example rule: FeedbackTo provide feedback on Amazon Q Developer, create an issue in the Amazon Q Developer public repository. For more detailed information, visit the Amazon Q for GitHub documentation. Footnotes
|
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
This PR successfully addresses issue #1342 by implementing defensive label validation to prevent gh issue create failures. The solution is well-executed and follows established patterns from the codebase.
Strengths
- Problem-focused solution: Directly addresses the reported failure mode with minimal, targeted changes
- Consistency: Follows the same validation pattern already established in
issue-triage.md - Clear documentation: The CRITICAL callout effectively communicates the importance of validation
- Proper maintenance: Sequential step renumbering maintains logical flow
Key Improvements Made
- Added explicit label fetching step (
gh label list) - Implemented cross-validation between selected and available labels
- Maintained procedural integrity with proper step numbering
- Added clear warnings about failure consequences
Minor Considerations
- Consider making the
gh label listcommand more explicit with repository parameters for broader applicability - The validation process could potentially be streamlined in future iterations
The implementation aligns well with the stated principles of tracer-bullets (get it working first) and subtraction-creates-value (minimal addition, maximum impact). This is a solid defensive fix that will prevent user frustration and wasted time.
Recommendation: Approve and merge. The changes are minimal, well-documented, and directly solve the reported problem.
| From the **Available Labels** section above, select appropriate labels based on: | ||
| Before selecting labels, run `gh label list` to get the list of labels that actually exist in the repository. | ||
|
|
||
| **CRITICAL**: Only labels from this list can be applied. Using a non-existent label will cause `gh issue create` to fail. |
There was a problem hiding this comment.
The addition of explicit label validation is a solid defensive programming practice that addresses the reported failure mode. The solution follows the established pattern from issue-triage.md and maintains consistency across the codebase. The CRITICAL callout effectively communicates the importance of this validation step to users.
| ## Step 4: Fetch Available Labels | ||
|
|
||
| From the **Available Labels** section above, select appropriate labels based on: | ||
| Before selecting labels, run `gh label list` to get the list of labels that actually exist in the repository. |
There was a problem hiding this comment.
Consider making the command more explicit by including the repository parameter to ensure consistency across different repositories. This would prevent potential issues when the procedure is used in contexts where the current directory might not be the target repository.
|
|
||
| ## Step 5: Build Issue Content | ||
| **Validation**: Cross-check each selected label against the list from Step 4. Only include labels that exist. | ||
|
|
There was a problem hiding this comment.
The validation note is well-placed and provides clear guidance. However, consider adding a brief example of what happens when validation fails to make the consequences more concrete for users who might skip this step.
| **Validation**: Cross-check each selected label against the list from Step 4. Only include labels that exist. | ||
|
|
||
| ## Step 6: Build Issue Content | ||
|
|
There was a problem hiding this comment.
Excellent step renumbering consistency. All subsequent steps have been properly updated to maintain sequential numbering, which preserves the logical flow of the procedure.
| - "rapid", "quick test" → tracer-bullets | ||
| - "accumulate", "compound" → snowball-method | ||
|
|
||
| ## Step 4: Select Labels |
There was a problem hiding this comment.
The original step structure was clean and direct. While the new validation steps are necessary for preventing failures, consider if there's a way to make this validation more seamless or automated rather than requiring manual cross-checking.
1 participant
Summary
gh issue createfailures when non-existent labels are appliedProblem
Issue #1342 reported that when creating GitHub issues with the
ghCLI, if a label doesn't exist, the entiregh issue createcommand fails. This forces the user to restart the entire issue creation process, wasting time and tokens.Solution
Added explicit validation steps to
knowledge/procedures/issue-creation-procedure.md:gh label listfirstThe fix is minimal (following the issue's request for "1 line should suffice") while being explicit enough to prevent the failure mode.
Implementation Details
.github/workflow-prompts/issue-triage.md:19Test Plan
Principles Applied
Closes #1342