bug: infrahub doesn't update the CoreGraphQLQuery query attribute properly from a query defined in a repository in a branch if the branch has a conflict

[wvandeun]

Component

Git Integration

Infrahub version

1.0.7

Current Behavior

Infrahub doesn't seem to properly update a CoreGraphQLQuery node's query attribute value, when that value is coming from a query that is defined in an external git repository in a branch, that has a conflict with main.
It seems that the value is being set, to the value of the query as defined in the main branch.

When you then update the query in the main branch (new commit in git repo), then the value of the query will be updated for the CoreGraphQLQuery node in main, but the node in the branch will still have main's old query value.

Additionally we may want change the Operational status should not be Error when we run into a conflict, but a more dedicated status with a different color.

Expected Behavior

The CoreGraphQLQuery query attribute contains the query as defined in the branch in the git repository, even if there's a conflict.

Steps to Reproduce

• create a git repository
• in the main branch, define a file test.gql with the following contents

  query tags {
    BuiltinTag {
      edges {
        node {
      id
      hfid
       }
     }
   }
  }

• in the root of the repository define a .infrahub.yml file with the following contents

---
queries:
 - name: test
   file_path: test.gql

• commit the changes
• create a new branch test-branch
• in the branch change the test.gql file to the following

query my_tags {
 BuiltinTag {
   edges {
     node {
   id
   hfid
     }
   }
 }
}

• commit the changes
• switch to main branch, edit the test.gql file to the following

 query tags_query {
  BuiltinTag {
    edges {
      node {
	id
	hfid
      }
    }
  }
}

• commit the changes and push them to a remote
• set up an instance of Infrahub
• set up the external repository in Infrahub
• the repo operational status will be set to Error
• the tasks will display a failing task because of the conflict
• the query will be properly imported into the main branch
• the same query node will exist in the branch test but have a query attribute value which is the value from the main branch

Additional Information

I haven't checked but we might have a similar issue for checks/transforms/generators/...