Feature Request
When a create_pull_request safe output fails (e.g. due to a transient GitHub API error during label application), the framework falls back to creating an issue instead of a PR. These fallback issues are currently created with no labels, making them hard to distinguish from normal issues in the repository.
Desired Behavior
Add a fallback_labels (or similar) config option to create_pull_request in GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG that specifies labels to apply to the fallback issue when PR creation fails.
Example config:
```json
"create_pull_request": {
"fallback_labels": ["failure", "automated"],
...
}
```
Context
We observed this in one of our repos where a transient "Could not resolve node ID" error during label application caused a fallback issue to be created. The PR itself was actually created successfully, but the label step failed due to GitHub API eventual consistency — the PR wasn't yet fully indexed when the label mutation ran immediately after creation.
Having a failure label on these fallback issues would make them easy to filter and triage.
Feature Request
When a
create_pull_requestsafe output fails (e.g. due to a transient GitHub API error during label application), the framework falls back to creating an issue instead of a PR. These fallback issues are currently created with no labels, making them hard to distinguish from normal issues in the repository.Desired Behavior
Add a
fallback_labels(or similar) config option tocreate_pull_requestinGH_AW_SAFE_OUTPUTS_HANDLER_CONFIGthat specifies labels to apply to the fallback issue when PR creation fails.Example config:
```json
"create_pull_request": {
"fallback_labels": ["failure", "automated"],
...
}
```
Context
We observed this in one of our repos where a transient "Could not resolve node ID" error during label application caused a fallback issue to be created. The PR itself was actually created successfully, but the label step failed due to GitHub API eventual consistency — the PR wasn't yet fully indexed when the label mutation ran immediately after creation.
Having a
failurelabel on these fallback issues would make them easy to filter and triage.