Skip to content

bug: diff skips updates to aware attributes of agnostic schema #9221

Description

@ajtmccarty

Component

API Server / GraphQL

Infrahub version

1.9.3

Current Behavior

the diff calculation logic will incorrectly exclude branch-aware attributes of branch-agnostic schemas if the object exists on the default branch

Expected Behavior

the diff calculation logic should correctly include any branch-aware attributes updated on the user's branch, regardless of whether the parent object exists on the default branch or not.

Steps to Reproduce

either create a branch-agnostic schema that includes branch-aware attributes or use the CoreReadOnlyRepository and its ref and commit attributes.

  1. create an instance of your object
  2. create a branch
  3. update the object's branch-aware attribute on the branch
  4. calculate the diff for the branch
  5. the update will not be visible

Additional Information

this bug initially presented as duplicated instances of a schema being created when a branch with an update to a CoreReadOnlyRepository.commit was merged to the default branch. the timeline of the problem was something like this
0. on a branch, update the commit of a CoreReadOnlyRepository to a new commit ID that includes a new schema that does not exist on the default branch

  1. merge the branch from step 0
  2. database-level changes are merged
    a. updates to CoreReadOnlyRepository.commit are not included b/c the diff was incorrectly excluding them
    b. the new schema added in step 1 is already merged to the default branch at the database level
  3. the merge repositories operations begin
  4. the task worker processing the merge repositories flow sees that the commit for the CoreReadOnlyRepository needs to be updated on the default branch and sends a request to update it via the SDK
  5. the API worker that picks up the request might have a stale version of the schema cached if the whole merge has not completed yet, which it probably has not
  6. the API worker sees that the new schema from step 0 needs to be added to the default branch and does so
  7. now there are two instances of this new schema, violating the uniqueness constraint on schema name and namespace

Metadata

Metadata

Assignees

Labels

priority/2This issue stalls work on the project or its dependents, it's a blocker for a releasetype/bugSomething isn't working as expected

Type

Fields

No fields configured for Bug.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions