Repository navigation
Handle the AI removing every mozilla patch when resolving conflicts. … - #431
Merged
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Manifest reread errors bypass failure handling and leave jobs in CREATED status.
1 open finding
What changed in this PR
Handles vendoring when AI conflict resolution removes all local patches, addressing #430.
Changes:
- Re-read patch metadata after AI resolution.
- Skip patch application and committing when none remain, adjusting revision counts.
- Add regression coverage for this workflow.
| File | Description |
|---|---|
| tests/mock_libraryprovider.py | Simulates patch removal after AI resolution. |
| tests/functionality_all_platforms.py | Tests successful vendoring with all patches removed. |
| tasktypes/vendoring.py | Adjusts patch processing and revision submission. |
| components/libraryprovider.py | Reads current patch state from moz.yaml. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…ixes #430 If the AI resolves a patch conflict by dropping every patch (e.g. they were all upstreamed), the library no longer has patches, but we decided what to do next from the moz.yaml as it was at the start of the run. The re-apply then failed with "there are no vendored patches defined", and had it got past that, committing the (empty) patches and the phabricator revision count would have failed too. This happened to libsrtp on the dev instance. Re-read the moz.yaml after the AI succeeds; if no patches remain, skip the re-apply and the patches commit and submit one fewer revision.
Re-reading the moz.yaml happened outside the error handling for re-applying the patches, so if the AI left it missing or malformed the exception escaped, the job stayed in CREATED, and the maintainer wasn't told. Before re-reading was added, the same problem surfaced in the re-apply and was handled. Move it inside that handler. Also treat a moz.yaml without a vendoring section as broken rather than as having no patches.
tomrittervg
force-pushed
the
2026-10-15-tjr-ai-removed-all-patches
branch
from
October 19, 2026 16:42
b78aa35 to
83fa3ae
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…Fixes #430
If the AI resolves a patch conflict by dropping every patch (e.g. they were all upstreamed), the library no longer has patches, but we decided what to do next from the moz.yaml as it was at the start of the run. The re-apply then failed with "there are no vendored patches defined", and had it got past that, committing the (empty) patches and the phabricator revision count would have failed too. This happened to libsrtp on the dev instance.
Re-read the moz.yaml after the AI succeeds; if no patches remain, skip the re-apply and the patches commit and submit one fewer revision.