Sonarly Claude Code
51311288e5
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)
Run yarn dev while server running on port 3000