perf(node): stop requesting the peer count of many relationships

[fatih-acar]

Why

The query the SDK renders for every cardinality-many relationship asks for count next to edges, and nothing reads it back: the relationship manager is built from edges alone, and the only counts the SDK consumes are the top-level pagination count and the hand-written member_of_groups { count } of infrahubctl info.

On the server that nested count is not free. Infrahub resolves it with a dedicated relationship_get_peer_count query per returned node and per relationship, awaited before the peers are loaded — which also splits the batched peer read (relationship_get_peer) into several partial queries. Attribute-kind relationships such as tags are rendered by every all() / filters() / get() call by default, so this cost is paid on nearly every SDK read.

Goal: stop asking for a value that is never used.

Non-goals: a server-side mitigation for SDKs already deployed (they keep sending count) — that is an Infrahub change, tracked separately.

What changed

• Queries generated by all(), filters(), get(), relationship fetch() and the hierarchical children / ancestors / descendants blocks no longer include count in cardinality-many relationship blocks.
• The top-level pagination count and the member_of_groups { count } of infrahubctl info are unchanged.
• Implementation: one line in RelationshipManagerBase._generate_query_data, shared by the async and sync managers. Response processing is untouched — RelationshipManager never looked at count.
• Tests: the two fixtures in tests/unit/sdk/test_node.py that pinned the nested field are updated, and the two _generate_query_data tests now assert the field is absent.

How to test

uv run pytest tests/unit/sdk

Measured against Infrahub with a component test that runs the exact query the SDK renders through a query-counting database — 25 TestPerson nodes carrying 2 peers per relationship, tags being an Attribute-kind relationship (rendered by default) and cars a Generic-kind one (rendered via include):

SDK call	DB queries with nested count (total / peer reads / count reads)	without
all("TestPerson")	62 / 8 / 25	9 / 1 / 0
all("TestPerson", include=["cars"])	122 / 13 / 50	16 / 2 / 0
all("TestPerson", prefetch_relationships=True)	38 / 2 / 25	9 / 1 / 0

Impact & rollout

• Backward compatibility: none. The field was never read by the SDK; users running their own documents through execute_graphql are unaffected.
• Performance: one fewer database query per returned node and per many relationship, and the peer reads batch into a single query again (see table).
• Deployment notes: safe to release; the server-side saving applies as soon as a client upgrades.

Checklist

• Tests added/updated
• Changelog entry added
• External docs updated — not applicable, the generated query shape is not documented
• Internal .md docs updated — not applicable

🤖 Generated with Claude Code

---

Summary by cubic

Stops requesting the count field on cardinality-many relationship blocks in SDK-generated queries, since nothing ever reads it—but Infrahub resolved it with one extra database query per returned node and per relationship, and it also prevented peer reads from being batched into a single query. Removing it cuts database queries substantially (for example, all("TestPerson") drops from 62 to 9 queries on a 25-node test) and restores peer-read batching. The top-level pagination count and the member_of_groups { count } used by infrahubctl info are unchanged.

^{Written for commit 68ce4cc. Summary will update on new commits.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff             @@
##           stable    #1294      +/-   ##
==========================================
+ Coverage   84.16%   84.23%   +0.07%     
==========================================
  Files         147      147              
  Lines       13045    13045              
  Branches     1930     1930              
==========================================
+ Hits        10979    10989      +10     
+ Misses       1503     1493      -10     
  Partials      563      563              

Flag	Coverage Δ
integration-tests	39.09% <ø> (+0.07%)	⬆️
python-3.10	57.05% <ø> (+0.07%)	⬆️
python-3.11	57.05% <ø> (+0.07%)	⬆️
python-3.12	57.05% <ø> (+0.07%)	⬆️
python-3.13	57.05% <ø> (+0.06%)	⬆️
python-3.14	57.07% <ø> (+0.07%)	⬆️
python-filler-3.12	23.68% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
infrahub_sdk/node/relationship.py	81.86% <ø> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}