fix(git): register transforms before objects during repository import [#9406] by lancamat1 · Pull Request #9460 · opsmill/infrahub

lancamat1 · 2026-06-04T13:46:14Z

Summary

During repository import, objects/ were imported before the .infrahub.yml Python transforms were registered. An object referencing a CoreTransformPython defined in the same repository (e.g. a CoreCustomWebhook with transformation: "MyTransform") therefore aborted the entire import with:

Unable to find the node MyTransform / CoreTransformPython in the database.

…leaving the repository in sync_status: error-import. Because the failure happened during object import, transforms/checks/generators were never registered either, so a retry could not converge.

Fixes #9406 (IFC-2669).

Change

Reorder InfrahubRepositoryIntegrator.import_objects_from_files so the end-to-end order is:

Schemas
GraphQL queries
Transforms (Python + Jinja2) — moved ahead of objects
Objects (+ menus)
Checks, generator definitions, artifact definitions

Transforms move before objects so same-repo references resolve. Generators and artifact definitions stay after objects because their targets reference groups created from the repository's own object files — moving them up would trade one failure for another. This splits the previously-bundled import_all_python_files call accordingly (the method is retained for its existing integration-test caller).

No schema, GraphQL, or database changes.

Tests

Extends the existing full-stack integration_docker car-dealership fixture and test_propose_change_repository.py (no new fixture repo):

US1 — a CoreCustomWebhook referencing the repo's existing WebhookTransformer Python transform; asserts transformation resolves after import.
US2 — a CoreStandardGroup defined as a repo object plus a generator definition targeting it; asserts the generator's targets resolves to the same-repo group (guards the objects-before-generators side of the ordering).

Validation:

✅ Against a source build (:local): test_propose_change_repository.py 4/4 pass.
❌ Against the released 1.9.6 image (no fix): test_load_initial_data fails with the exact issue error Unable to find the node WebhookTransformer / CoreTransformPython — confirming the tests are genuine regression guards.

Notes

Also adds package-lock.json to frontend/app/.gitignore (this project uses pnpm; an stray npm lockfile kept appearing).
dev/specs/ifc-2669-fix-import-order/ contains the spec/plan/tasks design record for the ticket.

🤖 Generated with Claude Code

Summary by cubic

Fixes repository import ordering so Python and Jinja2 transforms register before objects, allowing same-repo references (e.g., CoreCustomWebhook.transformation) to resolve. Keeps checks, generator definitions, and artifact definitions after objects so their targets to repo-defined groups still resolve. Aligns with IFC-2669.

Bug Fixes
- Reordered InfrahubRepositoryIntegrator.import_objects_from_files to: Schemas → GraphQL queries → Transforms (Python + Jinja2) → Objects → Checks/Generators/Artifacts.
- Removed import_all_python_files; tests now call import_python_check_definitions and import_python_transforms explicitly.
- Added a dedicated same-repo-references fixture and full-stack integration_docker test (TestSameRepoReferences) that verifies a webhook resolves its same-repo transform and a generator resolves a same-repo group.

^{Written for commit 94f7bd8. Summary will update on new commits.}

codspeed-hq · 2026-06-04T13:54:12Z

Merging this PR will not alter performance

✅ 12 untouched benchmarks

_{Comparing fix-import-order-ifc-2669 (dcec6df) with stable (2a1cff7)¹}

No successful run was found on stable (9d65300) during the generation of this report, so 2a1cff7 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

cubic-dev-ai

No issues found across 15 files

Confidence score: 5/5

Automated review surfaced no issues in the provided summaries.
No files require special attention.

_{Shadow auto-approve: would require human review. This reorders the repository import sequence to register transforms before objects, which is a critical business logic change in the core import pipeline that could break imports if incorrect, so it requires human review.

Re-trigger cubic}

polmichel

Thanks for your work and the fix on this issue, @lancamat1!
I've left comments that are mainly about code conventions and maintainability. We can also take over this work if you'd prefer.
One additional thing to note: we prefer to target the stable branch for bug fixes.
Of course, this makes sense only if this is a bug. However, the fixed.md part of the changelog seems to indicate that. In that case adding the "type/bug" label to the Github issue would also be required.
We want to target stable branch so customers don't have to upgrade to the next minor version to get the fix and only upgrade to the next patch version which is less impacting.

lancamat1 · 2026-06-05T11:14:44Z

Thanks so much for the thorough and kind review, @polmichel — really appreciate the time you took, and every pointer was spot-on. Pushed an update addressing all of them:

Comments referencing the issue / spec-kit / US tags (the fixture .infrahub.yml and the two test comments): trimmed to describe just the expected behavior, in line with dev/rules/code-doc-style.md. The two test comments now read as you suggested.
Changelog: renamed to 9406.fixed.md (issue number only, no +) and reduced to a single user-facing sentence, per dev/guidelines/changelog.md.
Spec-kit documents: removed from the PR — agreed they don't belong in the repo for a bug fix.
import_all_python_files: removed. Confirmed it has no workflow in catalogue.py and was only used by one integration test, which now calls the primitives directly and is renamed accordingly.
Target branch: retargeted to stable and added the type/bug label to the issue — thanks for explaining the patch-vs-minor rationale, that makes total sense. The branch was develop-based, so I replayed the single commit onto stable; it applied cleanly since the import code is identical there.

Thanks again — happy to iterate on anything else!

ajtmccarty

@ogenstad left a comment on the bug this PR fixes that is worth considering (#9406 (comment)). it looks like we probably need a more robust importing system that allows objects to reference transforms and vice versa

lancamat1 · 2026-06-08T07:40:54Z

Thanks @ajtmccarty! The fixed-ordering approach here was agreed as part of IFC-2669. It covers both reference directions in the current schema — objects → transforms (the reported case) and generators/artifacts → groups, which are objects and so import after. A more flexible / dependency-aware importer would be a larger piece of work; happy to open a follow-up issue to track it if we'd like to pursue it.

ogenstad · 2026-06-08T07:54:35Z

@ogenstad left a comment on the bug this PR fixes that is worth considering (#9406 (comment)). it looks like we probably need a more robust importing system that allows objects to reference transforms and vice versa

I was actually thinking about artifact definitions that refer to a group (same with generator definitions) but transforms should be fine to import earlier than we do now.

polmichel

LGTM on the backend side, I'll just ask the front-end team to validate the .gitignore modification before you merge. Fyi, I usually "squash" the commits (this is one of the option of the merge button) so that only one commit remains once the PR is merged. This gives a cleaner git history, I think. Thank you for the fix.

I've posted two optional comments but it would be great if you can:

move the comment closer to the code it explains
remove useless instructions from the test

…#9406] During repository import, objects were imported before Python transforms were registered, so an object referencing a same-repo CoreTransformPython (for example a CoreCustomWebhook.transformation) aborted the whole import with "Unable to find the node ... / CoreTransformPython in the database" and left the repository in error-import. Reorder import_objects_from_files so Python and Jinja2 transforms are registered before objects, while checks, generator definitions and artifact definitions stay after objects (their targets reference groups created from the repository's own object files). Tests: add a dedicated, isolated integration_docker fixture (same-repo-references) and TestSameRepoReferences that imports it through the full stack and asserts the webhook resolves its same-repo Python transform (US1) and a generator resolves a target group defined as a same-repo object (US2). The test fails against the released 1.9.6 image with the documented error and passes against a source build. Co-Authored-By: Claude Opus 4.8 <[email protected]> [skip ci] — only removes a .gitignore line; code identical to the previously CI-green commit.

polmichel

LGTM

lancamat1 requested review from a team as code owners June 4, 2026 13:46

github-actions Bot added group/backend Issue related to the backend (API Server, Git Agent) group/frontend Issue related to the frontend (React) type/spec A specification for an upcoming change to the project labels Jun 4, 2026

cubic-dev-ai Bot reviewed Jun 4, 2026

View reviewed changes

lancamat1 force-pushed the fix-import-order-ifc-2669 branch from 4b95d9e to d5b9b6d Compare June 4, 2026 14:40

polmichel reviewed Jun 5, 2026

View reviewed changes

lancamat1 force-pushed the fix-import-order-ifc-2669 branch from d5b9b6d to 2a83b95 Compare June 5, 2026 11:14

lancamat1 requested review from a team as code owners June 5, 2026 11:14

lancamat1 changed the base branch from develop to stable June 5, 2026 11:14

github-actions Bot removed the type/spec A specification for an upcoming change to the project label Jun 5, 2026

lancamat1 force-pushed the fix-import-order-ifc-2669 branch from 2a83b95 to 5c6898f Compare June 5, 2026 11:40

ajtmccarty reviewed Jun 5, 2026

View reviewed changes

polmichel approved these changes Jun 8, 2026

View reviewed changes

lancamat1 force-pushed the fix-import-order-ifc-2669 branch from 5c6898f to dcec6df Compare June 8, 2026 10:37

lancamat1 force-pushed the fix-import-order-ifc-2669 branch from dcec6df to 94f7bd8 Compare June 8, 2026 11:44

polmichel approved these changes Jun 8, 2026

View reviewed changes

lancamat1 merged commit 6f8abc2 into stable Jun 9, 2026
3 checks passed

lancamat1 deleted the fix-import-order-ifc-2669 branch June 9, 2026 11:04

Uh oh!

Conversation

lancamat1 commented Jun 4, 2026 • edited by cubic-dev-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change

Tests

Notes

Summary by cubic

Uh oh!

codspeed-hq Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will not alter performance

Footnotes

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

polmichel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lancamat1 commented Jun 5, 2026

Uh oh!

ajtmccarty left a comment

Choose a reason for hiding this comment

Uh oh!

lancamat1 commented Jun 8, 2026

Uh oh!

ogenstad commented Jun 8, 2026

Uh oh!

polmichel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

polmichel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lancamat1 commented Jun 4, 2026 •

edited by cubic-dev-ai Bot

Loading

codspeed-hq Bot commented Jun 4, 2026 •

edited

Loading