IFC-2536: Migrate InfrahubClient to graphql query for get and filters methods

[solababs]

Why

Prefect task files were making overfetching calls to client.all(), client.filters(), and client.get() that returned every attribute, relationship, and metadata field — but the tasks only consumed id (or a handful of fields). This caused unnecessary Neo4j reads, large GraphQL payloads, and slower task execution on every background worker cycle.

This PR replaces those calls with targeted execute_graphql() calls backed by purpose-built query model classes that request only the fields each task actually uses.

How to test

# Unit tests for every query model class
uv run pytest backend/tests/unit/display_labels/ backend/tests/unit/hfid/ \
    backend/tests/unit/git/test_git_repository_query.py \
    backend/tests/unit/generators/test_generator_instance_query.py \
    backend/tests/unit/computed_attribute/ -v

# Benchmark (200 nodes, 5 iterations — requires Neo4j testcontainer)
INFRAHUB_LOG_LEVEL=CRITICAL uv run pytest -v \
    backend/tests/benchmark/test_query_optimization.py --dist=no -s

# Full functional suite
uv run invoke backend.test-functional

Benchmark expected output (≥30% time reduction, ≥50% size reduction per task):

Task	Full fetch	Optimized	Time ↓	Payload ↓
display_labels	485 ms / 65 KB	97 ms / 12 KB	80%	82%
hfid	120 ms / 65 KB	28 ms / 12 KB	76%	82%
git	263 ms / 164 KB	90 ms / 31 KB	66%	81%

Impact & rollout

• Backward compatibility: no breaking changes — task outputs are identical, only the internal fetch mechanism changes
• Performance: 65–80% execution time reduction and 80–82% payload size reduction for the six migrated call sites
• Config/env changes: none
• Deployment notes: safe to deploy; no migrations, no schema changes, no flag required

Checklist

• Tests added/updated
• Changelog entry added (uv run towncrier create ...)
• External docs updated (if user-facing or ops-facing change)
• Internal .md docs updated (internal knowledge and AI code tools knowledge)
• I have reviewed AI generated content

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing optimize-prefect-queries-phase-3-ifc-2536 (a38d4ed) with develop (1e09e82)}

[dgarros]

are you using the Pydantic model generator from the SDK or have you generated this class using Claude directly ?

[solababs]

This is generated using claude

[ogenstad]

What we can do with the Pydantic model generator (https://docs.infrahub.app/infrahubctl/infrahubctl-graphql) is to have a reference to the GraphQL query in text and then by having it there we can run checks in the CI to validate that the query we've written is up to date based on the current core GraphQL schema shipped with Infrahub, i.e. the one stored here: https://github.com/opsmill/infrahub/blob/infrahub-v1.9.3/schema/schema.graphql. Basically together with a GraphQL query and the GraphQL schema we can generate Python bindings and validate that they are up to date in the CI. One of the thoughts around this JPD card was that we'd use this approach but it seems like this information was lost in the creation of that card. So the primary goal of the JPD card is to improve the performance by avoiding over fetching data, the secondary goal was to have queries defined as text and be able to both validate that they are up to date and that we have generated classes that match the queries. The intention is to start using this approach in multiple places within the backend but also get started in the frontend. This approach would not work for the changes in #9123 though since in that work we're directly querying for user defined nodes that doesn't exist in the core schema. But for the work in this PR it should be possible.

[ogenstad]

We will need a small change with regards to how this query would be executed. If you check this issue #8945. In short there's a caching feature of the backend that would cache the rendering and processing of the GraphQL queries, i.e. to convert them into a GraphQL document. But this only happens if the raw text of the query looks exactly the same. As such we don't want to have self.transform_id be hardcoded into the body of the query but instead we'd need to send it as variables in the SDK call to await client.execute_graphql()

[ogenstad]

I think a call like this should be fine with regards to pagination as we'd only expect to get a single result back, i.e. regarding the comments on pagination on the other PR.

[ogenstad]

These exclude lines are a bit problematic for anyone just running "ruff check ." which is a lot faster than using the invoke commands. I'd wonder what's failing in these generated files. Might it just be a matter of us having to run ruff check [filenames] --fix and ruff format [filenames]? I.e. when we generate them we should be able to format them correctly provided that there are no other violations in these files. For reference:

https://github.com/opsmill/infrahub/blob/infrahub-v1.9.3/tasks/backend.py#L260-L261

[ogenstad]

Note that we have a file called backend/infrahub/computed_attribute/graphql_queries.py in #9123 which would conflict with the module directory here backend/infrahub/computed_attribute/graphql_queries/. So could be that this PR should be rebased and reworked once the other one lives in develop

Actually this is probably the merge conflict for this PR.

[ogenstad]

I think we'd want the same approach for this as you have a bit further down where we have generator_instance_fetch.gql as a separate file. It make it clearer that we'd expect to the bindings for this be generated from the actual file. As it is inline here it looks like it's just part of the code.

Also we can probably combine the two queries TRANSFORM_QUERY_BY_NAME and TRANSFORM_QUERY_BY_IDS into one, then we just have the queries accept both of the parameters and it would use whatever we send in with with the variables.

[ogenstad]

Combining this into one query as per above would remove the if-statement here and we'd only have the get_variables() one.

[ogenstad]

I think that we might want to have pagination for this query if there's a high number of generator instances.

[solababs]

this request is for one instance, uses instance_nodes[0].id below