https://sonarly.com/issue/35597?type=bug
The settings roles page fails with a GraphQL validation error due to duplicate fragment definitions in the GetRoles query, preventing users from viewing or managing roles.
Fix: ## What Changed
Removed duplicate GraphQL fragment definitions from `getRolesQuery.ts`:
1. **Removed imports** (lines 7-8):
- `ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT`
- `ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT`
2. **Removed fragment inclusions** from the gql template (lines 20-21):
- `${ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT}`
- `${ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT}`
## Why This Fixes the Bug
The query was including the RLS fragment definitions twice:
- Once directly in `getRolesQuery.ts` (lines 20-21)
- Once inside `OBJECT_PERMISSION_FRAGMENT` (which is included on line 16)
When Apollo Client compiled the query, it encountered duplicate definitions of `RowLevelPermissionPredicateFragment` and `RowLevelPermissionPredicateGroupFragment`, causing the GraphQL validation error: "Fields '__type' conflict because they have differing arguments."
The fix removes the direct inclusion while keeping the fragments available through `OBJECT_PERMISSION_FRAGMENT`, which correctly defines them for its nested fields.
## Query Structure After Fix
The query still fetches all the same data:
- `getRoles.objectPermissions.rowLevelPermissionPredicates` uses the fragment from `OBJECT_PERMISSION_FRAGMENT`
- `getRoles.rowLevelPermissionPredicates` uses the same fragment definition (available in the query scope via `OBJECT_PERMISSION_FRAGMENT`)
- No duplicate definitions, no validation error
## Pattern Consistency
This fix aligns with the team's established pattern. Other queries using `OBJECT_PERMISSION_FRAGMENT` correctly omit direct RLS fragment imports:
- `upsertObjectPermissionsMutation.ts` ✓
- `userQueryFragment.ts` ✓
- `getRolesQuery.ts` ✓ (after this fix)
Sonarly Claude Code
51311288e5