Component
API Server / GraphQL
Infrahub version
1.9.0
Current Behavior
If a merge operation fails, it is possible for it to leave the branch partially merged, which will most likely leave data and/or schemas in an illegal state.
Expected Behavior
If a merge fails, we should roll back any changes made during the merge
Steps to Reproduce
not really reproducible in an easy way b/c it involves an unexpected failure
Additional Information
we have rollback handling for the 2 biggest portions of the merge logic: the graph merge and the schema migrations following the graph merge. if either of these fails, then all the changes that are part of that particular step are rolled back.
for example, if the graph merge fails, then all changes made as part of the graph merge are rolled back. if the schema migrations fail, then all changes made as part of the schema schema migrations are rolled back.
but there is logic between these steps that remains uncovered by rollback protection. and the rollback executed following a schema migrations failure is not exactly the same as the graph merge rollback.
ideally, all of the merge logic should covered by the same rollback protection
Component
API Server / GraphQL
Infrahub version
1.9.0
Current Behavior
If a merge operation fails, it is possible for it to leave the branch partially merged, which will most likely leave data and/or schemas in an illegal state.
Expected Behavior
If a merge fails, we should roll back any changes made during the merge
Steps to Reproduce
not really reproducible in an easy way b/c it involves an unexpected failure
Additional Information
we have rollback handling for the 2 biggest portions of the merge logic: the graph merge and the schema migrations following the graph merge. if either of these fails, then all the changes that are part of that particular step are rolled back.
for example, if the graph merge fails, then all changes made as part of the graph merge are rolled back. if the schema migrations fail, then all changes made as part of the schema schema migrations are rolled back.
but there is logic between these steps that remains uncovered by rollback protection. and the rollback executed following a schema migrations failure is not exactly the same as the graph merge rollback.
ideally, all of the merge logic should covered by the same rollback protection