https://sonarly.com/issue/15272?type=bug
The findMany and aggregate record queries both write to the same `Query.companies` cache key with incompatible `CompanyConnection` shapes, causing Apollo Client to overwrite one result with the other and producing undefined data access errors.
Fix: Added a GraphQL alias to aggregate queries to prevent Apollo cache collisions with findMany queries.
**Problem:** Both `useFindManyRecords` and `useAggregateRecords` issue GraphQL queries targeting the same field (e.g., `Query.companies`). In Apollo Client v4, these results collide in the cache — the aggregate result `{percentageEmptyLinkedinLink: 1}` overwrites the findMany result `{edges: [...], pageInfo: {...}, totalCount: 45}` (or vice versa), producing `undefined` data reads that trigger the TypeError.
**Fix:** The aggregate query now uses a GraphQL alias (`aggregate_companies: companies(filter: $filter)` instead of `companies(filter: $filter)`). This causes Apollo to store the aggregate result under a different cache key (`Query.aggregate_companies`) than the findMany result (`Query.companies`), eliminating the collision entirely.
**Changes:**
1. `generateAggregateQuery.ts` — Added `getAggregateQueryAlias()` helper and applied the alias in the generated query
2. `useAggregateRecords.ts` — Updated data access to read from the aliased key instead of `objectMetadataItem.namePlural`
3. Test files updated to match new query shape and mock response structure
The GraphQL operation name (`AggregateCompanies`) is unchanged, so `useRefetchAggregateQueries` continues to work without modification.
Sonarly Claude Code
5b1810d62e