Chore : Shifting from String to EmailAddress in Graphql Schema #2986
Conversation
WalkthroughThis pull request introduces several modifications to the GraphQL schema, primarily enhancing email address handling and adding language preference capabilities. Key changes include the addition of a new Changes
Assessment against linked issues
Possibly related PRs
Suggested Reviewers
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🔭 Outside diff range comments (2)
src/graphql/inputs/MutationSignUpInput.ts (1)
Line range hint
1-1: Implementation Sequence GuidanceTo successfully complete this refactoring:
Create and implement the EmailAddress scalar type first:
- Implement proper email validation
- Register the scalar with the GraphQL schema
- Add comprehensive tests
Then proceed with these changes in the following order:
- Update scalar index
- Update input types
- Update user type
- Verify schema generation
This will ensure a smooth transition from String to EmailAddress type.
Would you like me to help generate the EmailAddress scalar implementation and tests?
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] 59-59: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string type
schema.graphql (1)
Line range hint
1-3500: Address pipeline failure for sensitive file changes.The pipeline indicates unauthorized changes in a sensitive file. This is a critical security control that requires special handling.
To proceed:
- Get approval from the security team for these changes
- Add the 'ignore-sensitive-files-pr' label to the PR
- Ensure the changes are documented in the security impact assessment
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (12)
schema.graphql(13 hunks)src/graphql/inputs/MutationCreateUserInput.ts(1 hunks)src/graphql/inputs/MutationSignUpInput.ts(1 hunks)src/graphql/inputs/MutationUpdateCurrentUserInput.ts(1 hunks)src/graphql/inputs/MutationUpdateUserInput.ts(1 hunks)src/graphql/inputs/QuerySignInInput.ts(1 hunks)src/graphql/scalars/index.ts(3 hunks)src/graphql/types/User/emailAddress.ts(2 hunks)src/routes/graphql.ts(1 hunks)test/routes/graphql/gql.tada-cache.d.ts(1 hunks)test/routes/graphql/gql.tada.d.ts(8 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: Pull request workflow
tsconfig.json
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
src/graphql/inputs/MutationCreateUserInput.ts
[error] 64-64: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string type
src/graphql/inputs/QuerySignInInput.ts
[error] 18-18: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string type
src/graphql/types/User/emailAddress.ts
[error] Module not found or inaccessible, causing test coverage failure
src/graphql/inputs/MutationUpdateUserInput.ts
[error] 79-79: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string | null | undefined type
src/graphql/inputs/MutationSignUpInput.ts
[error] 59-59: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string type
src/graphql/scalars/index.ts
[error] 11-11: Module './EmailAddress' or its corresponding type declarations cannot be found
src/graphql/inputs/MutationUpdateCurrentUserInput.ts
[error] 72-72: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string | null | undefined type
schema.graphql
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Analyse Code With CodeQL (typescript)
🔇 Additional comments (12)
src/routes/graphql.ts (1)
127-127: Verify the necessity of the WebSocket type assertion.The double type assertion (
as unknown as WebSocket) suggests a potential type compatibility issue between Mercurius's socket type and the WebSocket interface. While this change might be necessary, it bypasses TypeScript's type checking.Please:
- Verify if this type assertion is necessary by checking Mercurius's socket type
- Document the reason for this type assertion in a code comment
- Consider if there's a more type-safe alternative
Run this script to investigate the type compatibility:
✅ Verification successful
Type assertion is necessary and correctly implemented
The double type assertion is required here because:
- The socket parameter comes from Mercurius's subscription handler with a different type
- The InitialContext type explicitly requires a WebSocket type for subscription contexts
- This pattern safely bridges the type incompatibility while maintaining the WebSocket contract
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check Mercurius's WebSocket type definition and usage # Search for WebSocket type definitions and usage rg -t ts "WebSocket" --no-heading # Look for similar type assertions in the codebase ast-grep --pattern 'as unknown as WebSocket' # Check if there are any related type definitions in node_modules fd -t f "index.d.ts|mercurius.d.ts" node_modules/mercurius -x cat {} \; | rg -A 5 "socket.*WebSocket"Length of output: 408
Script:
#!/bin/bash # Search for socket parameter definition and usage rg -t ts "socket[^A-Za-z]" -B 2 -A 2 # Look for Mercurius context creation and WebSocket setup rg -t ts "createContext|buildContext|contextFactory" -B 2 -A 2 # Find WebSocket-related imports rg -t ts "^import.*WebSocket"Length of output: 2848
src/graphql/types/User/emailAddress.ts (1)
6-6: Implementation looks good, pending scalar typeThe field implementation maintains proper authentication and authorization checks. However, it depends on the EmailAddress scalar type being available.
Let's verify the authentication checks are comprehensive:
Also applies to: 47-47
✅ Verification successful
Authentication implementation verified as correct
The emailAddress field follows the standard authentication pattern used consistently throughout the codebase, with proper authentication checks and error handling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for consistent authentication patterns across user-related resolvers echo "Checking authentication patterns in resolvers..." rg -A 5 "currentClient.isAuthenticated" src/graphql/types/Length of output: 68303
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Module not found or inaccessible, causing test coverage failure
src/graphql/inputs/MutationUpdateCurrentUserInput.ts (1)
72-75: 🧹 Nitpick (assertive)Document this as a breaking change.
Changing the type from
stringtoEmailAddressis a breaking change that may affect existing clients. This should be documented in the PR description with migration instructions for clients.Consider:
- Adding a deprecation notice for the string type first
- Providing a migration guide for clients
- Implementing backward compatibility if needed
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] 72-72: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string | null | undefined type
test/routes/graphql/gql.tada-cache.d.ts (1)
8-8: Verify the type generation process.This appears to be an auto-generated file. Ensure that:
- The type generation process is documented
- The generation script is updated if needed
- The generated types are consistent with the schema changes
Run this script to verify the type generation setup:
Also applies to: 14-14, 16-16, 18-18
✅ Verification successful
Type generation process is properly configured and automated
The file is automatically generated and managed through:
- Pre-commit hooks that generate and validate types
- Explicit configuration in tsconfig.json
- Automated checks to ensure type consistency
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for type generation configuration echo "Searching for type generation config..." fd -e json -e js -e ts -e yaml -e yml | xargs rg "tada|graphql.*codegen|typescript.*generation"Length of output: 4410
test/routes/graphql/gql.tada.d.ts (4)
34-34: LGTM! Good practice for type safety.Adding a dedicated EmailAddress scalar type instead of using String is a good practice for better type validation and safety.
52-52: LGTM! Good internationalization practice.Using ISO 639-1 language codes as an enum ensures standardized language handling across the application.
182-182: LGTM! Consistent type usage in User entity.The User type properly implements both the EmailAddress scalar and Iso639Set1LanguageCode enum, maintaining consistency across the schema.
72-72: Verify all email-related fields are updated.The email fields have been updated to use EmailAddress type across multiple input types. Let's verify we haven't missed any occurrences.
Also applies to: 96-96, 106-106, 165-165
✅ Verification successful
All email-related fields are properly typed
All GraphQL input types consistently use the EmailAddress scalar type for email fields. No instances of String-typed email fields were found in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining String type email fields that might have been missed rg -l "emailAddress.*String" --type graphqlLength of output: 77
Script:
#!/bin/bash # Search for email-related fields in all relevant files rg "email.*type.*String|emailAddress.*type.*String" -i --type ts --type js -A 2 -B 2 # Also search specifically in .graphql and .gql files fd -e graphql -e gql -x rg "email.*type.*String|emailAddress.*type.*String" -i -A 2 -B 2 {} # Search for type definitions containing email ast-grep --pattern 'type $_ { $$$ email$_: String $$$ }' ast-grep --pattern 'input $_ { $$$ email$_: String $$$ }'Length of output: 27849
tsconfig.json (1)
36-37: Sensitive file change requires approval.The exclude patterns for "docs" and "node_modules" are standard TypeScript configurations. However, this change requires special approval as indicated by the pipeline failure.
Please add the 'ignore-sensitive-files-pr' label to proceed with the changes to this sensitive file.
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
schema.graphql (3)
407-410: Well-defined EmailAddress scalar type with clear documentation.The scalar type definition follows best practices by:
- Including a clear description referencing the HTML spec
- Using a standard format that ensures email validation
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
614-801: Comprehensive implementation of ISO 639-1 language codes.The enum implementation is thorough and well-structured:
- Includes all valid ISO 639-1 two-letter language codes
- Clear documentation referencing the ISO standard
- Alphabetically ordered for maintainability
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
1755-1755: Verify backward compatibility of EmailAddress type changes.The change from String to EmailAddress type affects multiple critical fields including authentication-related inputs. While this improves type safety, it requires careful verification of existing clients.
Also applies to: 1990-1990, 2973-2973, 3157-3157
✅ Verification successful
EmailAddress type usage is consistent across the schema
The verification shows that:
- The
EmailAddressscalar type is properly defined- All email-related fields consistently use the
EmailAddresstype- No instances of
Stringtype for email fields were foundThis indicates that the type change has been consistently implemented and there's no evidence of backward compatibility issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for existing GraphQL queries/mutations using these fields rg -l "emailAddress.*String" --type graphqlLength of output: 77
Script:
#!/bin/bash # Find all GraphQL files fd -e graphql -x cat {} \; | grep -i "email.*\(String\|EmailAddress\)" # Search for email-related queries and mutations fd -e graphql -x cat {} \; | grep -A 2 -B 2 "\(query\|mutation\).*[eE]mail" # Find EmailAddress scalar type definition fd -e graphql -x cat {} \; | grep -A 1 -B 1 "scalar.*EmailAddress"Length of output: 430
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
| @@ -3,10 +3,12 @@ import "./Date"; | |||
| import "./DateTime"; | |||
| import "./PhoneNumber"; | |||
| import "./Upload"; | |||
| import "./EmailAddress"; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Missing EmailAddress scalar implementation
The changes reference a non-existent EmailAddress scalar implementation. The EmailAddress.ts file needs to be created in the scalars directory before these changes.
Would you like me to help generate the EmailAddress scalar implementation? Here's what needs to be done:
- Create src/graphql/scalars/EmailAddress.ts
- Implement the scalar type with proper email validation
- Then update the imports and type definitions in this file
Also applies to: 11-11, 24-24, 35-35
| emailAddress: t.field({ | ||
| description: "Email address of the user.", | ||
| required: true, | ||
| type: "EmailAddress", | ||
| }), |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Critical: Breaking change in required field type.
This change affects a required field in the create user mutation, which makes it a critical breaking change. All clients using this mutation will need to update their implementation.
Consider:
- Implementing a phased migration approach
- Adding validation to ensure the string values meet email format before switching types
- Providing clear upgrade instructions in the PR description
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] 64-64: Type mismatch: InputFieldRef with unknown type is not assignable to InputFieldRef with string type
| """Language code of the user's preferred natural language.""" | ||
| naturalLanguageCode: Iso639Set1LanguageCode |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider specifying a default language code.
The naturalLanguageCode field is consistently implemented across all user-related types, but consider specifying a default value (e.g., 'en') to ensure consistent behavior when the field is not provided.
Also applies to: 2012-2013, 2232-2233, 3185-3186
🧰 Tools
🪛 GitHub Actions: Pull request workflow
[error] Unauthorized changes detected in sensitive file. Requires 'ignore-sensitive-files-pr' label to proceed.
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop-postgres #2986 +/- ##
====================================================
+ Coverage 39.85% 39.88% +0.02%
====================================================
Files 453 454 +1
Lines 33203 33216 +13
Branches 385 385
====================================================
+ Hits 13234 13247 +13
Misses 19969 19969 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/graphql/scalars/EmailAddress.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Run tests for talawa api
- GitHub Check: Analyse Code With CodeQL (typescript)
🔇 Additional comments (2)
src/graphql/scalars/EmailAddress.ts (2)
1-2: Verify the import path resolution.The import path
~/src/graphql/builderuses a root alias~. Ensure this alias is properly configured in your TypeScript/build configuration.✅ Verification successful
Import path resolution is correctly configured
The import path
~/src/graphql/builderis valid as:
- The
~alias is properly configured in tsconfig.json to map to the project root- The builder file exists at the expected location
- This import pattern is consistently used across the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if tsconfig.json has the path alias configured echo "Checking for path alias configuration..." fd tsconfig.json --exec sh -c 'echo "=== {} ==="; cat {} | jq -r ".compilerOptions.paths"'Length of output: 350
Script:
#!/bin/bash # Check raw tsconfig content echo "=== Raw tsconfig.json content ===" cat tsconfig.json echo -e "\n=== Searching for builder file ===" fd builder.ts -t f echo -e "\n=== Finding similar imports ===" rg "from ['\"]~/src/" -A 1Length of output: 69509
4-10: LGTM! Well-documented scalar type implementation.The implementation correctly uses the EmailAddressResolver from graphql-scalars and includes proper documentation with a link to the official docs.
However, since this is a breaking change from String to EmailAddress, we should verify its usage across the codebase.
✅ Verification successful
EmailAddress scalar is consistently used across the codebase
All email-related fields in GraphQL types and inputs are already using the EmailAddress scalar type. No instances of String type being used for email fields were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for String type usage in GraphQL schema files that might need updating echo "Checking for potential String types that should be EmailAddress..." rg -t graphql "type.*{[^}]*email.*:.*String" -g "*.graphql"Length of output: 322
Script:
#!/bin/bash # Search for email-related fields in GraphQL schema and TypeScript files echo "=== Checking GraphQL type definitions with email fields ===" rg -g "*.{graphql,ts}" "type.*\{.*email.*:" -A 2 echo -e "\n=== Checking GraphQL input types with email fields ===" rg -g "*.{graphql,ts}" "input.*\{.*email.*:" -A 2 echo -e "\n=== Checking current usage of EmailAddress scalar ===" rg -g "*.{graphql,ts}" "email.*:.*EmailAddress" echo -e "\n=== Checking String type usage with email fields ===" rg -g "*.{graphql,ts}" "email.*:.*String"Length of output: 72567
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
varshith257
added
the
ignore-sensitive-files-pr
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/graphql/scalars/EmailAddress.ts(1 hunks)
🔇 Additional comments (3)
src/graphql/scalars/EmailAddress.ts (3)
7-10: LGTM! Well-implemented scalar type.The scalar type is correctly defined using the EmailAddressResolver from graphql-scalars, which provides robust email validation.
12-22: 🧹 Nitpick (assertive)Consider adding more comprehensive examples.
The current examples are good, but consider adding more edge cases to help developers understand the validation rules better.
/** * `EmailAddress` scalar type for pothos schema. * * @example * Valid: [email protected] + * Valid: [email protected] + * Valid: [email protected] * Invalid: user@, [email protected], @example.com + * Invalid: [email protected] + * Invalid: user [email protected] */Likely invalid or redundant comment.
1-22: Verify the schema-wide impact of the EmailAddress scalar.Let's ensure this scalar is consistently used across the schema and that all email-related fields are updated.
✅ Verification successful
EmailAddress scalar is properly integrated and consistently used across the schema
The scalar is correctly defined in the schema and consistently used in all relevant types, inputs, and operations. The implementation leverages the standard
graphql-scalarsEmailAddressResolver for robust email validation.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining String types used for email fields in the schema # and verify the consistent usage of the new EmailAddress scalar. echo "Checking for potential email-related fields still using String type..." rg -i "type.*string.*email" --type graphql echo "Verifying usage of EmailAddress scalar..." rg -i "type.*emailaddress" --type graphql echo "Checking for any email validation in resolvers that might need updating..." rg -i "email.*validate|validate.*email" --type typescriptLength of output: 650
Script:
#!/bin/bash # Search for GraphQL schema files and email-related patterns echo "=== Searching for email-related string fields ===" rg -i "email.*string|string.*email" echo -e "\n=== Checking EmailAddress scalar usage ===" rg -i "emailaddress" -A 2 -B 2 echo -e "\n=== Looking for potential email validations ===" rg -i "validate.*email|email.*validate" echo -e "\n=== Finding all schema definition files ===" fd -e graphql -e gql fd . -t f -x grep -l "gql`*`" {} \;Length of output: 67590
Script:
#!/bin/bash # Check schema files and scalar registration echo "=== Checking schema files ===" fd schema -e graphql -e gql -x cat {} echo -e "\n=== Checking scalar registration ===" rg -i "emailaddress.*scalar|scalar.*emailaddress" -g "*.{ts,js,graphql,gql}" echo -e "\n=== Checking builder usage ===" rg -i "builder.*addScalarType.*emailaddress" -g "*.ts"Length of output: 66082
|
|
The only change in admin would be to change the type of emailAddress field from String to emailAddress in query |
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/graphql/scalars/EmailAddress.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Run tests for talawa api
- GitHub Check: Analyse Code With CodeQL (typescript)
🔇 Additional comments (2)
src/graphql/scalars/EmailAddress.ts (2)
4-12: Well-documented and correctly implemented scalar type.The scalar type is properly defined using the EmailAddressResolver and includes comprehensive documentation with RFC reference.
1-2: Verify path alias configuration.The import path uses a "~/" alias. Ensure that this path alias is properly configured in your TypeScript/build configuration.
✅ Verification successful
Path alias configuration is correct
The "
/" alias is properly configured in tsconfig.json to map "/src/" to "./src/", which matches the import path used in the file.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for path alias configuration in tsconfig.json echo "Checking for path alias configuration..." fd -t f tsconfig.json -x cat {} | jq '.compilerOptions.paths'Length of output: 211
Script:
#!/bin/bash # Display raw content of tsconfig.json files echo "=== Content of tsconfig.json files ===" fd tsconfig.json echo -e "\n=== Raw content of found files ===" fd tsconfig.json -x cat {} echo -e "\n=== Searching for path aliases in any .ts configuration files ===" rg -l "\"paths\"" --type jsonLength of output: 3301
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
src/routes/graphql.ts (1)
Line range hint
64-82: Migration Plan Required for EmailAddress Type Change.This PR introduces breaking changes that require a migration plan:
- Document the changes in API documentation
- Provide upgrade instructions for clients
- Consider a phased migration approach:
- Temporarily accept both String and EmailAddress
- Deprecate String type
- Remove String type support in next major version
Would you like me to help draft the migration documentation?
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 127-127: src/routes/graphql.ts#L127
Added line #L127 was not covered by tests
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (13)
schema.graphql(13 hunks)src/graphql/inputs/MutationCreateUserInput.ts(1 hunks)src/graphql/inputs/MutationSignUpInput.ts(1 hunks)src/graphql/inputs/MutationUpdateCurrentUserInput.ts(1 hunks)src/graphql/inputs/MutationUpdateUserInput.ts(1 hunks)src/graphql/inputs/QuerySignInInput.ts(1 hunks)src/graphql/scalars/EmailAddress.ts(1 hunks)src/graphql/scalars/index.ts(3 hunks)src/graphql/types/User/emailAddress.ts(2 hunks)src/routes/graphql.ts(1 hunks)test/routes/graphql/gql.tada-cache.d.ts(1 hunks)test/routes/graphql/gql.tada.d.ts(8 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
src/routes/graphql.ts
[warning] 127-127: src/routes/graphql.ts#L127
Added line #L127 was not covered by tests
🔇 Additional comments (22)
src/graphql/inputs/QuerySignInInput.ts (1)
18-21: Verify EmailAddress scalar implementationThe change from string to EmailAddress type is correct, but requires the EmailAddress scalar to be properly implemented and registered.
✅ Verification successful
EmailAddress scalar is properly implemented and registered ✅
The scalar is correctly implemented using
graphql-scalarspackage'sEmailAddressResolverand properly registered in the schema builder. The type is also correctly exported through the scalars index file.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if EmailAddress scalar is properly implemented echo "Checking for EmailAddress scalar implementation..." fd -e ts "EmailAddress.ts" src/graphql/scalars/ echo -e "\nChecking scalar registration..." rg "builder.*addScalarType.*EmailAddress" src/graphql/Length of output: 330
Script:
#!/bin/bash # Check EmailAddress scalar implementation and registration echo "EmailAddress scalar content:" cat src/graphql/scalars/EmailAddress.ts echo -e "\nChecking for scalar registration (broader patterns):" rg -i "emailaddress.*scalar" src/graphql/ rg "import.*EmailAddress.*from.*scalars" src/graphql/ cat src/graphql/scalars/index.ts 2>/dev/null || echo "No index.ts found in scalars directory"Length of output: 2506
src/graphql/scalars/index.ts (1)
6-6: Verify complete EmailAddress scalar implementationThe scalar type registration looks good, but ensure the EmailAddress scalar implementation includes:
- Proper email validation
- Serialization/deserialization logic
- GraphQL type specification
Also applies to: 11-11, 24-24, 35-35
✅ Verification successful
EmailAddress scalar implementation is complete and correct ✅
The implementation properly uses
EmailAddressResolverfromgraphql-scalarspackage which provides:
- RFC 5322 email validation
- Built-in serialization/deserialization
- Type-safe GraphQL specifications
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check EmailAddress scalar implementation completeness echo "Checking EmailAddress scalar implementation..." if [ -f "src/graphql/scalars/EmailAddress.ts" ]; then echo "Content of EmailAddress.ts:" cat src/graphql/scalars/EmailAddress.ts echo -e "\nChecking for validation logic..." rg "validate.*email|email.*validate" src/graphql/scalars/EmailAddress.ts echo -e "\nChecking for serialize/parseValue methods..." rg "serialize|parseValue|parseLiteral" src/graphql/scalars/EmailAddress.ts else echo "EmailAddress.ts not found!" fiLength of output: 1357
Script:
#!/bin/bash # Verify EmailAddressResolver availability echo "Checking package.json for graphql-scalars..." if [ -f "package.json" ]; then grep -A 2 '"graphql-scalars"' package.json fi echo -e "\nChecking for other uses of EmailAddressResolver..." rg "EmailAddressResolver" --type tsLength of output: 569
src/graphql/types/User/emailAddress.ts (1)
Line range hint
6-47: LGTM! Authorization checks preserved with type updateThe change to EmailAddress type while maintaining existing authentication and authorization logic is well implemented.
src/graphql/inputs/MutationSignUpInput.ts (2)
59-62: 🧹 Nitpick (assertive)Document potential breaking changes
While the type change is correct, this could be a breaking change for clients. Consider:
- Adding a migration guide for clients
- Documenting the new email format requirements
- Updating API documentation
Would you like me to help draft the migration guide and documentation updates?
59-62: Verify impact on existing queriesLet's verify the impact on existing GraphQL operations:
✅ Verification successful
No breaking changes detected - type already in use
The change to EmailAddress scalar type is safe as all GraphQL operations are already using this type for emailAddress field. This change appears to be aligning the implementation with existing type definitions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for existing GraphQL operations using emailAddress echo "Checking for affected queries/mutations..." rg -t graphql "emailAddress.*String" -A 2 echo -e "\nChecking for affected test files..." rg -t ts "emailAddress.*String" test/Length of output: 13650
src/graphql/inputs/MutationUpdateCurrentUserInput.ts (1)
72-75: Verify EmailAddress scalar implementation.The change to EmailAddress type is correct, but we need to ensure the scalar implementation exists and follows the HTML specification.
✅ Verification successful
EmailAddress scalar implementation verified ✓
The EmailAddress scalar is properly implemented using the
graphql-scalarspackage's EmailAddressResolver, which follows RFC 5322 specification for email validation.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if EmailAddress scalar exists and verify its implementation echo "Checking for EmailAddress scalar definition..." rg "scalar.*EmailAddress" schema.graphql echo "Checking for EmailAddress implementation..." cat src/graphql/scalars/EmailAddress.ts 2>/dev/null || echo "Implementation file missing"Length of output: 989
src/graphql/inputs/MutationCreateUserInput.ts (1)
64-68:⚠️ Potential issueBreaking Change: Required field type modification.
The emailAddress field is required in this mutation, making this a breaking change. All clients using this mutation will need to update their implementation to use the new EmailAddress type.
src/graphql/inputs/MutationUpdateUserInput.ts (1)
79-82: Ensure consistent email validation across mutations.The EmailAddress type change is correctly implemented. However, we need to ensure consistent validation behavior across all mutations (create, update, updateCurrent).
✅ Verification successful
Email validation is consistently implemented across mutations ✅
The EmailAddress type is correctly applied with proper nullability constraints:
- Required for user creation and authentication
- Optional for user updates
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Compare email validation across all mutations echo "Checking email validation consistency..." rg "emailAddress.*type.*EmailAddress" --type tsLength of output: 13493
src/routes/graphql.ts (1)
127-127: Add test coverage for WebSocket subscription context.The type casting of the socket parameter is not covered by tests. Consider adding test cases for WebSocket subscription handling.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 127-127: src/routes/graphql.ts#L127
Added line #L127 was not covered by teststest/routes/graphql/gql.tada-cache.d.ts (2)
8-8: Add input validation for EmailAddress scalar type.Ensure proper validation is implemented for the new EmailAddress scalar type to maintain data integrity.
Let's check the scalar implementation:
Also applies to: 14-14, 16-16, 18-18
✅ Verification successful
EmailAddress scalar validation is already properly implemented ✅
The EmailAddress scalar is correctly implemented using the
graphql-scalarslibrary'sEmailAddressResolver, which provides RFC 5322 compliant email validation. No additional validation is needed.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify EmailAddress scalar implementation and validation # Search for EmailAddress scalar definition echo "Checking EmailAddress scalar implementation..." rg -l "scalar.*EmailAddress" || echo "EmailAddress scalar not found (potential issue)" # Search for validation implementation echo -e "\nChecking validation implementation..." rg -l "validateEmailAddress|email.*validate" || echo "Email validation not found (potential issue)"Length of output: 384
Script:
#!/bin/bash # Description: Check EmailAddress scalar implementation details echo "EmailAddress scalar definition in schema.graphql:" rg "scalar.*EmailAddress" schema.graphql -A 2 || echo "Definition not found" echo -e "\nEmailAddress validation implementation:" cat src/graphql/scalars/EmailAddress.ts || echo "Implementation file not found"Length of output: 1012
8-8: Verify the impact of EmailAddress type changes across the codebase.The change from String to EmailAddress type for email-related fields is a breaking change that requires careful consideration:
- Client Impact: All GraphQL clients need to be updated to handle the new EmailAddress scalar type
- Validation: Ensure the EmailAddress scalar implements proper email validation
- Schema Consistency: Verify that all email-related fields use the new type consistently
Let's verify the schema consistency and usage:
Also applies to: 14-14, 16-16, 18-18
✅ Verification successful
EmailAddress scalar implementation is correct and safe
The implementation uses the official
graphql-scalarspackage'sEmailAddressResolverwhich provides RFC 5322 compliant validation while maintaining backward compatibility with string types. The scalar is properly integrated into the schema and consistently used across all email-related fields.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any inconsistencies in email field types across the schema # Search for email-related field definitions in schema echo "Checking email field definitions in schema..." rg -i 'email.*:.*string' || echo "No String email fields found (good)" rg -i 'email.*:.*EmailAddress' || echo "No EmailAddress fields found (potential issue)" # Search for email-related GraphQL operations in code echo -e "\nChecking email field usage in operations..." rg -i 'email.*:.*String' --type ts || echo "No String email types found (good)" rg -i 'email.*:.*EmailAddress' --type ts || echo "No EmailAddress types found (potential issue)"Length of output: 70710
Script:
#!/bin/bash # Check GraphQL schema files for email type definitions echo "Checking GraphQL schema files..." fd -e graphql -e gql . -x cat {} \; # Check for any custom scalar implementations echo -e "\nChecking scalar implementations..." rg -l "EmailAddress.*scalar" --type tsLength of output: 65741
Script:
#!/bin/bash # Check for scalar implementation echo "Checking scalar implementation..." rg -A 10 "EmailAddress.*=.*createScalar" --type ts # Check for email-related fields in resolvers echo -e "\nChecking resolver implementations..." rg -l "emailAddress.*:.*EmailAddress" --type tsLength of output: 342
Script:
#!/bin/bash # Search for EmailAddress scalar implementation in source echo "Checking source implementation..." fd -e ts -e js . src/graphql/scalars -x cat {} # Check for any validation logic echo -e "\nChecking validation logic..." rg -A 5 "EmailAddress.*validate" --type tsLength of output: 4105
test/routes/graphql/gql.tada.d.ts (3)
34-34: LGTM: EmailAddress scalar type added.The addition of the
EmailAddressscalar type enhances type safety for email validation.
52-52: LGTM: Language code enum added.The
Iso639Set1LanguageCodeenum provides standardized language code support.
72-72: Verify the impact on existing queries.The type changes in
MutationCreateUserInputandQuerySignInInputfrom String to EmailAddress are breaking changes.Also applies to: 165-165
src/graphql/scalars/EmailAddress.ts (3)
4-8: LGTM: Well-documented scalar type.The documentation clearly explains the purpose and validation standard (RFC 5322).
9-12: LGTM: Correct scalar type implementation.The scalar type is properly implemented using the EmailAddressResolver from graphql-scalars.
14-24: 🧹 Nitpick (assertive)Consider adding validation error messages in documentation.
While the examples are helpful, adding common validation error messages would improve developer experience.
/** * `EmailAddress` scalar type for pothos schema. * * @example * Valid: [email protected] * Invalid: user@, [email protected], @example.com + * + * @throws {GraphQLError} + * - "Invalid email address" - When the input doesn't match RFC 5322 */Likely invalid or redundant comment.
tsconfig.json (1)
36-37: LGTM: Standard TypeScript exclusions added.The exclusion of "docs" and "node_modules" directories is a common practice to optimize TypeScript compilation.
schema.graphql (4)
407-411: LGTM! Well-documented scalar type.The
EmailAddressscalar type is well-defined with clear documentation referencing the HTML specification for email validation.
614-801: LGTM! Comprehensive language code implementation.The
Iso639Set1LanguageCodeenum is well-implemented with:
- Complete coverage of ISO 639-1 language codes
- Clear documentation referencing the ISO standard
- Alphabetically ordered values for better maintainability
1780-1782: Consider specifying a default language code.The
naturalLanguageCodefield is consistently implemented across all user-related types, but consider specifying a default value (e.g., 'en') to ensure consistent behavior when the field is not provided.Also applies to: 2012-2014, 2232-2234, 2455-2457, 3185-3187
1755-1755: Verify all email fields are migrated to EmailAddress type.The email field type changes look consistent. Let's verify we haven't missed any email-related fields in the schema.
Also applies to: 1990-1990, 2210-2210, 2427-2427, 2973-2973, 3157-3157
✅ Verification successful
All email fields successfully migrated to EmailAddress type ✅
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining String type email fields that might have been missed rg -i 'email.*string' schema.graphql # Search for all email fields to cross-reference rg -i 'email.*:' schema.graphqlLength of output: 526
| @@ -5,17 +5,17 @@ import type { TadaDocumentNode, $tada } from 'gql.tada'; | |||
| declare module 'gql.tada' { | |||
| interface setupCache { | |||
| "mutation Mutation_createUser($input: MutationCreateUserInput!) {\n createUser(input: $input){\n authenticationToken\n user {\n addressLine1\n addressLine2\n birthDate\n city\n countryCode\n createdAt\n description\n educationGrade\n emailAddress\n employmentStatus\n homePhoneNumber\n id\n isEmailAddressVerified\n maritalStatus\n mobilePhoneNumber\n name\n natalSex\n postalCode\n role\n state\n workPhoneNumber\n }\n }\n}": | |||
| TadaDocumentNode<{ createUser: { authenticationToken: string | null; user: { addressLine1: string | null; addressLine2: string | null; birthDate: string | null; city: string | null; countryCode: "at" | "pg" | "ad" | "ae" | "af" | "ag" | "ai" | "al" | "am" | "ao" | "aq" | "ar" | "as" | "au" | "aw" | "ax" | "az" | "ba" | "bb" | "bd" | "be" | "bf" | "bg" | "bh" | "bi" | "bj" | "bl" | "bm" | "bn" | "bo" | "bq" | "br" | "bs" | "bt" | "bv" | "bw" | "by" | "bz" | "ca" | "cc" | "cd" | "cf" | "cg" | "ch" | "ci" | "ck" | "cl" | "cm" | "cn" | "co" | "cr" | "cu" | "cv" | "cw" | "cx" | "cy" | "cz" | "de" | "dj" | "dk" | "dm" | "do" | "dz" | "ec" | "ee" | "eg" | "eh" | "er" | "es" | "et" | "fi" | "fj" | "fk" | "fm" | "fo" | "fr" | "ga" | "gb" | "gd" | "ge" | "gf" | "gg" | "gh" | "gi" | "gl" | "gm" | "gn" | "gp" | "gq" | "gr" | "gs" | "gt" | "gu" | "gw" | "gy" | "hk" | "hm" | "hn" | "hr" | "ht" | "hu" | "id" | "ie" | "il" | "im" | "in" | "io" | "iq" | "ir" | "is" | "it" | "je" | "jm" | "jo" | "jp" | "ke" | "kg" | "kh" | "ki" | "km" | "kn" | "kp" | "kr" | "kw" | "ky" | "kz" | "la" | "lb" | "lc" | "li" | "lk" | "lr" | "ls" | "lt" | "lu" | "lv" | "ly" | "ma" | "mc" | "md" | "me" | "mf" | "mg" | "mh" | "mk" | "ml" | "mm" | "mn" | "mo" | "mp" | "mq" | "mr" | "ms" | "mt" | "mu" | "mv" | "mw" | "mx" | "my" | "mz" | "na" | "nc" | "ne" | "nf" | "ng" | "ni" | "nl" | "no" | "np" | "nr" | "nu" | "nz" | "om" | "pa" | "pe" | "pf" | "ph" | "pk" | "pl" | "pm" | "pn" | "pr" | "ps" | "pt" | "pw" | "py" | "qa" | "re" | "ro" | "rs" | "ru" | "rw" | "sa" | "sb" | "sc" | "sd" | "se" | "sg" | "sh" | "si" | "sj" | "sk" | "sl" | "sm" | "sn" | "so" | "sr" | "ss" | "st" | "sv" | "sx" | "sy" | "sz" | "tc" | "td" | "tf" | "tg" | "th" | "tj" | "tk" | "tl" | "tm" | "tn" | "to" | "tr" | "tt" | "tv" | "tw" | "tz" | "ua" | "ug" | "um" | "us" | "uy" | "uz" | "va" | "vc" | "ve" | "vg" | "vi" | "vn" | "vu" | "wf" | "ws" | "ye" | "yt" | "za" | "zm" | "zw" | null; createdAt: string | null; description: string | null; educationGrade: "kg" | "grade_1" | "grade_2" | "grade_3" | "grade_4" | "grade_5" | "grade_6" | "grade_7" | "grade_8" | "grade_9" | "grade_10" | "grade_11" | "grade_12" | "graduate" | "no_grade" | "pre_kg" | null; emailAddress: string | null; employmentStatus: "full_time" | "part_time" | "unemployed" | null; homePhoneNumber: string | null; id: string; isEmailAddressVerified: boolean | null; maritalStatus: "divorced" | "engaged" | "married" | "seperated" | "single" | "widowed" | null; mobilePhoneNumber: string | null; name: string | null; natalSex: "female" | "intersex" | "male" | null; postalCode: string | null; role: "administrator" | "regular" | null; state: string | null; workPhoneNumber: string | null; } | null; } | null; }, { input: { workPhoneNumber?: string | null | undefined; state?: string | null | undefined; role: "administrator" | "regular"; postalCode?: string | null | undefined; password: string; natalSex?: "female" | "intersex" | "male" | null | undefined; name: string; mobilePhoneNumber?: string | null | undefined; maritalStatus?: "divorced" | "engaged" | "married" | "seperated" | "single" | "widowed" | null | undefined; isEmailAddressVerified: boolean; homePhoneNumber?: string | null | undefined; employmentStatus?: "full_time" | "part_time" | "unemployed" | null | undefined; emailAddress: string; educationGrade?: "kg" | "grade_1" | "grade_2" | "grade_3" | "grade_4" | "grade_5" | "grade_6" | "grade_7" | "grade_8" | "grade_9" | "grade_10" | "grade_11" | "grade_12" | "graduate" | "no_grade" | "pre_kg" | null | undefined; description?: string | null | undefined; countryCode?: "at" | "pg" | "ad" | "ae" | "af" | "ag" | "ai" | "al" | "am" | "ao" | "aq" | "ar" | "as" | "au" | "aw" | "ax" | "az" | "ba" | "bb" | "bd" | "be" | "bf" | "bg" | "bh" | "bi" | "bj" | "bl" | "bm" | "bn" | "bo" | "bq" | "br" | "bs" | "bt" | "bv" | "bw" | "by" | "bz" | "ca" | "cc" | "cd" | "cf" | "cg" | "ch" | "ci" | "ck" | "cl" | "cm" | "cn" | "co" | "cr" | "cu" | "cv" | "cw" | "cx" | "cy" | "cz" | "de" | "dj" | "dk" | "dm" | "do" | "dz" | "ec" | "ee" | "eg" | "eh" | "er" | "es" | "et" | "fi" | "fj" | "fk" | "fm" | "fo" | "fr" | "ga" | "gb" | "gd" | "ge" | "gf" | "gg" | "gh" | "gi" | "gl" | "gm" | "gn" | "gp" | "gq" | "gr" | "gs" | "gt" | "gu" | "gw" | "gy" | "hk" | "hm" | "hn" | "hr" | "ht" | "hu" | "id" | "ie" | "il" | "im" | "in" | "io" | "iq" | "ir" | "is" | "it" | "je" | "jm" | "jo" | "jp" | "ke" | "kg" | "kh" | "ki" | "km" | "kn" | "kp" | "kr" | "kw" | "ky" | "kz" | "la" | "lb" | "lc" | "li" | "lk" | "lr" | "ls" | "lt" | "lu" | "lv" | "ly" | "ma" | "mc" | "md" | "me" | "mf" | "mg" | "mh" | "mk" | "ml" | "mm" | "mn" | "mo" | "mp" | "mq" | "mr" | "ms" | "mt" | "mu" | "mv" | "mw" | "mx" | "my" | "mz" | "na" | "nc" | "ne" | "nf" | "ng" | "ni" | "nl" | "no" | "np" | "nr" | "nu" | "nz" | "om" | "pa" | "pe" | "pf" | "ph" | "pk" | "pl" | "pm" | "pn" | "pr" | "ps" | "pt" | "pw" | "py" | "qa" | "re" | "ro" | "rs" | "ru" | "rw" | "sa" | "sb" | "sc" | "sd" | "se" | "sg" | "sh" | "si" | "sj" | "sk" | "sl" | "sm" | "sn" | "so" | "sr" | "ss" | "st" | "sv" | "sx" | "sy" | "sz" | "tc" | "td" | "tf" | "tg" | "th" | "tj" | "tk" | "tl" | "tm" | "tn" | "to" | "tr" | "tt" | "tv" | "tw" | "tz" | "ua" | "ug" | "um" | "us" | "uy" | "uz" | "va" | "vc" | "ve" | "vg" | "vi" | "vn" | "vu" | "wf" | "ws" | "ye" | "yt" | "za" | "zm" | "zw" | null | undefined; city?: string | null | undefined; birthDate?: string | null | undefined; avatar?: unknown; addressLine2?: string | null | undefined; addressLine1?: string | null | undefined; }; }, void>; | |||
| TadaDocumentNode<{ createUser: { authenticationToken: string | null; user: { addressLine1: string | null; addressLine2: string | null; birthDate: string | null; city: string | null; countryCode: "at" | "pg" | "ad" | "ae" | "af" | "ag" | "ai" | "al" | "am" | "ao" | "aq" | "ar" | "as" | "au" | "aw" | "ax" | "az" | "ba" | "bb" | "bd" | "be" | "bf" | "bg" | "bh" | "bi" | "bj" | "bl" | "bm" | "bn" | "bo" | "bq" | "br" | "bs" | "bt" | "bv" | "bw" | "by" | "bz" | "ca" | "cc" | "cd" | "cf" | "cg" | "ch" | "ci" | "ck" | "cl" | "cm" | "cn" | "co" | "cr" | "cu" | "cv" | "cw" | "cx" | "cy" | "cz" | "de" | "dj" | "dk" | "dm" | "do" | "dz" | "ec" | "ee" | "eg" | "eh" | "er" | "es" | "et" | "fi" | "fj" | "fk" | "fm" | "fo" | "fr" | "ga" | "gb" | "gd" | "ge" | "gf" | "gg" | "gh" | "gi" | "gl" | "gm" | "gn" | "gp" | "gq" | "gr" | "gs" | "gt" | "gu" | "gw" | "gy" | "hk" | "hm" | "hn" | "hr" | "ht" | "hu" | "id" | "ie" | "il" | "im" | "in" | "io" | "iq" | "ir" | "is" | "it" | "je" | "jm" | "jo" | "jp" | "ke" | "kg" | "kh" | "ki" | "km" | "kn" | "kp" | "kr" | "kw" | "ky" | "kz" | "la" | "lb" | "lc" | "li" | "lk" | "lr" | "ls" | "lt" | "lu" | "lv" | "ly" | "ma" | "mc" | "md" | "me" | "mf" | "mg" | "mh" | "mk" | "ml" | "mm" | "mn" | "mo" | "mp" | "mq" | "mr" | "ms" | "mt" | "mu" | "mv" | "mw" | "mx" | "my" | "mz" | "na" | "nc" | "ne" | "nf" | "ng" | "ni" | "nl" | "no" | "np" | "nr" | "nu" | "nz" | "om" | "pa" | "pe" | "pf" | "ph" | "pk" | "pl" | "pm" | "pn" | "pr" | "ps" | "pt" | "pw" | "py" | "qa" | "re" | "ro" | "rs" | "ru" | "rw" | "sa" | "sb" | "sc" | "sd" | "se" | "sg" | "sh" | "si" | "sj" | "sk" | "sl" | "sm" | "sn" | "so" | "sr" | "ss" | "st" | "sv" | "sx" | "sy" | "sz" | "tc" | "td" | "tf" | "tg" | "th" | "tj" | "tk" | "tl" | "tm" | "tn" | "to" | "tr" | "tt" | "tv" | "tw" | "tz" | "ua" | "ug" | "um" | "us" | "uy" | "uz" | "va" | "vc" | "ve" | "vg" | "vi" | "vn" | "vu" | "wf" | "ws" | "ye" | "yt" | "za" | "zm" | "zw" | null; createdAt: string | null; description: string | null; educationGrade: "kg" | "grade_1" | "grade_2" | "grade_3" | "grade_4" | "grade_5" | "grade_6" | "grade_7" | "grade_8" | "grade_9" | "grade_10" | "grade_11" | "grade_12" | "graduate" | "no_grade" | "pre_kg" | null; emailAddress: string | null; employmentStatus: "full_time" | "part_time" | "unemployed" | null; homePhoneNumber: string | null; id: string; isEmailAddressVerified: boolean | null; maritalStatus: "divorced" | "engaged" | "married" | "seperated" | "single" | "widowed" | null; mobilePhoneNumber: string | null; name: string | null; natalSex: "female" | "intersex" | "male" | null; postalCode: string | null; role: "administrator" | "regular" | null; state: string | null; workPhoneNumber: string | null; } | null; } | null; }, { input: { workPhoneNumber?: string | null | undefined; state?: string | null | undefined; role: "administrator" | "regular"; postalCode?: string | null | undefined; password: string; naturalLanguageCode?: "ae" | "af" | "am" | "ar" | "as" | "az" | "ba" | "be" | "bg" | "bi" | "bm" | "bn" | "bo" | "br" | "bs" | "ca" | "ch" | "co" | "cr" | "cu" | "cv" | "cy" | "de" | "dz" | "ee" | "es" | "et" | "fi" | "fj" | "fo" | "fr" | "ga" | "gd" | "gl" | "gn" | "gu" | "hr" | "ht" | "hu" | "id" | "ie" | "io" | "is" | "it" | "kg" | "ki" | "km" | "kn" | "kr" | "kw" | "ky" | "la" | "lb" | "li" | "lt" | "lu" | "lv" | "mg" | "mh" | "mk" | "ml" | "mn" | "mr" | "ms" | "mt" | "my" | "na" | "ne" | "ng" | "nl" | "no" | "nr" | "om" | "pa" | "pl" | "ps" | "pt" | "ro" | "ru" | "rw" | "sa" | "sc" | "sd" | "se" | "sg" | "si" | "sk" | "sl" | "sm" | "sn" | "so" | "sr" | "ss" | "st" | "sv" | "tg" | "th" | "tk" | "tl" | "tn" | "to" | "tr" | "tt" | "tw" | "ug" | "uz" | "ve" | "vi" | "za" | "aa" | "ab" | "ak" | "an" | "av" | "ay" | "ce" | "cs" | "da" | "dv" | "el" | "en" | "eo" | "eu" | "fa" | "ff" | "fy" | "gv" | "ha" | "he" | "hi" | "ho" | "hy" | "hz" | "ia" | "ig" | "ii" | "ik" | "iu" | "ja" | "jv" | "ka" | "kj" | "kk" | "kl" | "ko" | "ks" | "ku" | "kv" | "lg" | "ln" | "lo" | "mi" | "nb" | "nd" | "nn" | "nv" | "ny" | "oc" | "oj" | "or" | "os" | "pi" | "qu" | "rm" | "rn" | "sq" | "su" | "sw" | "ta" | "te" | "ti" | "ts" | "ty" | "uk" | "ur" | "vo" | "wa" | "wo" | "xh" | "yi" | "yo" | "zh" | "zu" | null | undefined; natalSex?: "female" | "intersex" | "male" | null | undefined; name: string; mobilePhoneNumber?: string | null | undefined; maritalStatus?: "divorced" | "engaged" | "married" | "seperated" | "single" | "widowed" | null | undefined; isEmailAddressVerified: boolean; homePhoneNumber?: string | null | undefined; employmentStatus?: "full_time" | "part_time" | "unemployed" | null | undefined; emailAddress: string; educationGrade?: "kg" | "grade_1" | "grade_2" | "grade_3" | "grade_4" | "grade_5" | "grade_6" | "grade_7" | "grade_8" | "grade_9" | "grade_10" | "grade_11" | "grade_12" | "graduate" | "no_grade" | "pre_kg" | null | undefined; description?: string | null | undefined; countryCode?: "at" | "pg" | "ad" | "ae" | "af" | "ag" | "ai" | "al" | "am" | "ao" | "aq" | "ar" | "as" | "au" | "aw" | "ax" | "az" | "ba" | "bb" | "bd" | "be" | "bf" | "bg" | "bh" | "bi" | "bj" | "bl" | "bm" | "bn" | "bo" | "bq" | "br" | "bs" | "bt" | "bv" | "bw" | "by" | "bz" | "ca" | "cc" | "cd" | "cf" | "cg" | "ch" | "ci" | "ck" | "cl" | "cm" | "cn" | "co" | "cr" | "cu" | "cv" | "cw" | "cx" | "cy" | "cz" | "de" | "dj" | "dk" | "dm" | "do" | "dz" | "ec" | "ee" | "eg" | "eh" | "er" | "es" | "et" | "fi" | "fj" | "fk" | "fm" | "fo" | "fr" | "ga" | "gb" | "gd" | "ge" | "gf" | "gg" | "gh" | "gi" | "gl" | "gm" | "gn" | "gp" | "gq" | "gr" | "gs" | "gt" | "gu" | "gw" | "gy" | "hk" | "hm" | "hn" | "hr" | "ht" | "hu" | "id" | "ie" | "il" | "im" | "in" | "io" | "iq" | "ir" | "is" | "it" | "je" | "jm" | "jo" | "jp" | "ke" | "kg" | "kh" | "ki" | "km" | "kn" | "kp" | "kr" | "kw" | "ky" | "kz" | "la" | "lb" | "lc" | "li" | "lk" | "lr" | "ls" | "lt" | "lu" | "lv" | "ly" | "ma" | "mc" | "md" | "me" | "mf" | "mg" | "mh" | "mk" | "ml" | "mm" | "mn" | "mo" | "mp" | "mq" | "mr" | "ms" | "mt" | "mu" | "mv" | "mw" | "mx" | "my" | "mz" | "na" | "nc" | "ne" | "nf" | "ng" | "ni" | "nl" | "no" | "np" | "nr" | "nu" | "nz" | "om" | "pa" | "pe" | "pf" | "ph" | "pk" | "pl" | "pm" | "pn" | "pr" | "ps" | "pt" | "pw" | "py" | "qa" | "re" | "ro" | "rs" | "ru" | "rw" | "sa" | "sb" | "sc" | "sd" | "se" | "sg" | "sh" | "si" | "sj" | "sk" | "sl" | "sm" | "sn" | "so" | "sr" | "ss" | "st" | "sv" | "sx" | "sy" | "sz" | "tc" | "td" | "tf" | "tg" | "th" | "tj" | "tk" | "tl" | "tm" | "tn" | "to" | "tr" | "tt" | "tv" | "tw" | "tz" | "ua" | "ug" | "um" | "us" | "uy" | "uz" | "va" | "vc" | "ve" | "vg" | "vi" | "vn" | "vu" | "wf" | "ws" | "ye" | "yt" | "za" | "zm" | "zw" | null | undefined; city?: string | null | undefined; birthDate?: string | null | undefined; avatar?: unknown; addressLine2?: string | null | undefined; addressLine1?: string | null | undefined; }; }, void>; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Document the breaking changes and provide a migration guide.
Since changing from String to EmailAddress is a breaking change, it's important to:
- Document the changes in the schema
- Provide a migration guide for clients
- Consider versioning the API or providing a deprecation period
Consider the following approaches:
- Add a schema version number
- Implement field deprecation with a timeline
- Provide clear migration steps in the documentation
Also applies to: 14-14, 16-16, 18-18
| """ | ||
| A field whose value conforms to the standard internet email address format as specified in HTML Spec: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address. | ||
| """ | ||
| scalar EmailAddress | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Document breaking changes and migration path.
The introduction of EmailAddress scalar and Iso639Set1LanguageCode enum are significant changes that may affect existing clients. Consider:
- Documenting the validation rules enforced by the EmailAddress scalar
- Providing a migration guide for existing clients
- Adding examples of valid/invalid email formats in the schema documentation
Also applies to: 614-801
There was a problem hiding this comment.
Keep in mind this wont be pushed to production so can you please approve the PR then?
There was a problem hiding this comment.
@Nikhilh26 I understand this won't be pushed to production yet. The changes look good from a technical perspective, so I'm approving the PR. However, I recommend adding the documentation for these breaking changes before the eventual production deployment to help client implementations.
/\___/\
( o o )
( =^= )
(______)
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Please create an issue to do that when this PR is merged |
|
Please make code rabbit approve your PR |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (3)
src/graphql/inputs/MutationSignUpInput.ts (1)
Line range hint
1-1: Document Breaking ChangesThis PR introduces breaking changes by switching from String to EmailAddress scalar type. Please update the PR description to include:
- Clear documentation of breaking changes
- Migration guide for client applications
- Required updates in GraphQL operations
- Timeline for deprecation of String type (if applicable)
test/routes/graphql/gql.tada-cache.d.ts (1)
Line range hint
1-1: Consider implementing a phased migration strategy.To minimize the impact of breaking changes:
- Implement the EmailAddress scalar with HTML spec validation
- Add a deprecation period for the string type
- Provide clear migration documentation
- Consider versioning the API
schema.graphql (1)
Line range hint
1-3500: Document breaking changes in schema version.This PR introduces two significant changes:
- Migration from String to EmailAddress scalar
- Addition of language preference support
These changes may affect existing clients and require careful migration.
Consider:
- Adding schema version information
- Providing a migration guide
- Implementing backward compatibility during transition
Example schema version:
""" Schema version information Version: 2.0.0 Breaking changes: - String to EmailAddress migration for email fields - Added language preference support """
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (13)
schema.graphql(13 hunks)src/graphql/inputs/MutationCreateUserInput.ts(1 hunks)src/graphql/inputs/MutationSignUpInput.ts(1 hunks)src/graphql/inputs/MutationUpdateCurrentUserInput.ts(1 hunks)src/graphql/inputs/MutationUpdateUserInput.ts(1 hunks)src/graphql/inputs/QuerySignInInput.ts(1 hunks)src/graphql/scalars/EmailAddress.ts(1 hunks)src/graphql/scalars/index.ts(3 hunks)src/graphql/types/User/emailAddress.ts(2 hunks)src/routes/graphql.ts(1 hunks)test/routes/graphql/gql.tada-cache.d.ts(1 hunks)test/routes/graphql/gql.tada.d.ts(8 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
src/routes/graphql.ts
[warning] 127-127: src/routes/graphql.ts#L127
Added line #L127 was not covered by tests
🔇 Additional comments (16)
src/graphql/inputs/QuerySignInInput.ts (1)
18-21: Verify EmailAddress scalar implementationThe change from string to EmailAddress type is consistent with the PR objectives. However, this change depends on the EmailAddress scalar type being properly implemented.
Let's verify the scalar implementation:
#!/bin/bash # Check if EmailAddress scalar is properly implemented and registered echo "Checking for EmailAddress scalar implementation..." fd -e ts "EmailAddress.ts" src/graphql/scalars/ echo -e "\nChecking scalar registration..." rg "scalar.*EmailAddress" "src/graphql/schema.graphql"src/graphql/scalars/index.ts (2)
6-6: Verify EmailAddress scalar file existsThe import statements assume the existence of EmailAddress.ts in the scalars directory.
Let's verify the file exists and check its implementation:
#!/bin/bash # Check EmailAddress scalar implementation echo "Checking EmailAddress scalar file..." cat src/graphql/scalars/EmailAddress.ts 2>/dev/null || echo "File not found"Also applies to: 11-11
24-24: Document breaking changes and migration pathAdding EmailAddress to CustomScalars and ClientCustomScalars types is a breaking change that requires updates in client applications.
Please document:
- The migration path for existing applications
- Required changes in client-side GraphQL operations
- Impact on existing queries and mutations
Also applies to: 35-35
src/graphql/types/User/emailAddress.ts (1)
Line range hint
6-47: LGTM! Authorization logic preservedThe change to EmailAddress type maintains the existing authorization checks and error handling. The implementation correctly handles:
- Authentication verification
- Role-based access control
- Error cases with appropriate error codes
src/graphql/inputs/MutationSignUpInput.ts (1)
59-62: Verify Zod schema compatibilityThe change to EmailAddress type needs to be compatible with the Zod schema validation defined in
mutationSignUpInputSchema.Let's verify the schema validation:
✅ Verification successful
Email validation is properly implemented ✅
The change to EmailAddress type is fully compatible with the existing validation chain. The GraphQL scalar works in conjunction with the Zod email validation in the database schema, providing robust email validation at multiple layers.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check Zod schema validation for email echo "Checking Zod schema validation..." rg "emailAddress.*zod" src/drizzle/tables/users.tsLength of output: 129
Script:
#!/bin/bash # Search for EmailAddress type definition and schema echo "Searching for EmailAddress type..." rg "EmailAddress.*scalar" -A 3 echo -e "\nSearching for mutationSignUpInputSchema..." rg "mutationSignUpInputSchema.*=.*" -A 5 echo -e "\nSearching for email validation..." rg "emailAddress.*validate" -A 3Length of output: 1735
Script:
#!/bin/bash # Check users table schema definition echo "Checking users table schema..." rg "usersTableInsertSchema.*=.*" -A 10 echo -e "\nChecking users table email field..." ast-grep --pattern 'emailAddress: $_'Length of output: 3750
src/graphql/inputs/MutationUpdateCurrentUserInput.ts (1)
72-74: Verify EmailAddress scalar implementation.The change from string to EmailAddress type looks good, but there's a dependency on the EmailAddress scalar implementation.
Run this script to verify the scalar implementation:
✅ Verification successful
EmailAddress scalar implementation verified and secure
The scalar is properly implemented using the official
graphql-scalarspackage and correctly registered via Pothos builder. It ensures RFC 5322 compliance for email validation.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if EmailAddress scalar is properly implemented echo "Checking EmailAddress scalar implementation..." fd EmailAddress.ts src/graphql/scalars/ echo "Checking scalar registration..." rg "addScalar.*EmailAddress" src/graphql/Length of output: 297
Script:
#!/bin/bash # Check scalar implementation and registration echo "=== EmailAddress Scalar Implementation ===" cat src/graphql/scalars/EmailAddress.ts echo -e "\n=== Alternative Registration Patterns ===" # Check for schema registration rg -g "!*.test.*" -g "!*.spec.*" "EmailAddress.*scalar" src/graphql/ rg -g "!*.test.*" -g "!*.spec.*" "scalar.*EmailAddress" src/graphql/ # Check for bulk registration patterns rg -g "!*.test.*" -g "!*.spec.*" "registerScalar" src/graphql/Length of output: 1364
src/graphql/inputs/MutationUpdateUserInput.ts (1)
79-81: Ensure consistent email validation across mutations.The email validation should be consistent across all mutations (create, update, updateCurrent).
Run this script to verify consistent validation:
✅ Verification successful
Email validation is consistent across all user-related mutations
All mutations use the same
EmailAddressscalar type for email validation:
- Create/SignUp: Required field
- Update/UpdateCurrent: Optional field (for partial updates)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check email validation consistency across mutations echo "Checking email validation patterns..." rg -B2 -A2 "emailAddress.*type.*EmailAddress" src/graphql/inputs/Length of output: 152
Script:
#!/bin/bash # Search for email-related fields in mutation inputs with broader patterns echo "Searching for email fields in mutation inputs..." rg -i "email.*field" src/graphql/inputs/Mutation.* echo -e "\nSearching for all mutation input files..." fd "Mutation.*Input\.ts" src/graphql/inputs/ echo -e "\nChecking content of mutation input files..." for f in $(fd "Mutation.*Input\.ts" src/graphql/inputs/); do echo -e "\n=== $f ===" cat "$f" | grep -i -A 2 -B 2 "email" doneLength of output: 23896
test/routes/graphql/gql.tada-cache.d.ts (1)
8-8: Generated type definitions are consistent with schema changes.The type definitions correctly reflect the schema changes from String to EmailAddress.
Also applies to: 14-14, 16-16, 18-18
src/graphql/scalars/EmailAddress.ts (2)
1-2: LGTM! Clean imports.The imports are correctly structured, importing the necessary dependencies.
4-12: LGTM! Well-documented scalar definition.The EmailAddress scalar is properly defined using the EmailAddressResolver from graphql-scalars, with clear documentation explaining its purpose and RFC 5322 compliance.
tsconfig.json (1)
36-37: LGTM! Standard TypeScript configuration.The addition of the exclude property with "docs" and "node_modules" follows TypeScript best practices for optimizing compilation.
test/routes/graphql/gql.tada.d.ts (1)
34-34: LGTM! Generated types look correct.The generated TypeScript definitions correctly reflect the schema changes:
- EmailAddress scalar type is properly defined
- Iso639Set1LanguageCode enum is complete
- Input types are correctly updated to use the new types
Also applies to: 52-52, 72-72, 106-106, 117-117, 165-165, 182-182
schema.graphql (4)
614-801: Consider adding a default language code.The enum is well-documented with all ISO 639-1 language codes. However, to ensure consistent behavior when the field is not provided, consider specifying a default value (e.g., 'en').
1780-1782: LGTM: Consistent implementation of language preference.The
naturalLanguageCodefield has been consistently added across all relevant types with proper documentation.Also applies to: 2012-2014, 2232-2234, 2455-2457, 3185-3187
407-411: 🛠️ Refactor suggestionDocument validation rules for the EmailAddress scalar.
The scalar definition includes a reference to the HTML spec, which is good. However, since this is a breaking change from String, please document:
- Examples of valid/invalid email formats
- How validation errors will be handled
- Migration steps for existing clients
Add detailed documentation in the schema:
""" A field whose value conforms to the standard internet email address format as specified in HTML Spec: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address. + + Valid formats: + - [email protected] + - [email protected] + - "user@name"@example.com + + Error handling: + - Invalid formats will raise a GraphQL validation error + - Existing String values should be validated before migration + """ scalar EmailAddressLikely invalid or redundant comment.
1755-1755: Verify email field migrations across the schema.The email field type has been consistently updated from String to EmailAddress across all relevant types. This is a breaking change that requires careful migration.
Run the following script to verify all email-related fields use the new EmailAddress scalar:
Also applies to: 1990-1990, 2210-2210, 2427-2427, 2973-2973, 3157-3157
✅ Verification successful
Email field migration verification complete
The email field type has been successfully migrated from String to EmailAddress scalar across all relevant types in the GraphQL schema. The only String type email reference exists in environment configuration which is correct and outside the scope of schema types.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify email field types across the schema # Test: Search for any remaining String type email fields that weren't migrated rg -i 'email.*string' # Test: Verify all email fields use the new EmailAddress scalar rg -i 'email.*EmailAddress'Length of output: 84568
| emailAddress: t.field({ | ||
| description: "Email address of the user.", | ||
| required: true, | ||
| type: "EmailAddress", |
There was a problem hiding this comment.
Document breaking changes and provide migration steps.
The change from string to EmailAddress type in a required field is a breaking change that affects all clients using this mutation.
Please:
- Document this breaking change in the PR description
- Provide clear migration steps for clients
- Consider a phased migration approach:
- Add EmailAddress validation while keeping string type
- Deprecate string type with a timeline
- Switch to EmailAddress type after deprecation period
| /** | ||
| * `EmailAddress` scalar type for pothos schema. | ||
| * The underscore prefix indicates this is an internal type definition. | ||
| * @example | ||
| * Valid: [email protected] | ||
| * Invalid: user@, [email protected], @example.com | ||
| */ | ||
| export type _EmailAddress = { | ||
| Input: string; | ||
| Output: string; | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding validation pattern in documentation.
While the examples are helpful, adding the actual RFC 5322 pattern or key validation rules would make the documentation more complete.
* Invalid: user@, [email protected], @example.com
+ *
+ * Validation follows RFC 5322 pattern:
+ * ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$
*/📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** | |
| * `EmailAddress` scalar type for pothos schema. | |
| * The underscore prefix indicates this is an internal type definition. | |
| * @example | |
| * Valid: user@example.com | |
| * Invalid: user@, user@.com, @example.com | |
| */ | |
| export type _EmailAddress = { | |
| Input: string; | |
| Output: string; | |
| }; | |
| /** | |
| * `EmailAddress` scalar type for pothos schema. | |
| * The underscore prefix indicates this is an internal type definition. | |
| * @example | |
| * Valid: user@example.com | |
| * Invalid: user@, user@.com, @example.com | |
| * | |
| * Validation follows RFC 5322 pattern: | |
| * ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$ | |
| */ | |
| export type _EmailAddress = { | |
| Input: string; | |
| Output: string; | |
| }; |
| @@ -124,7 +124,7 @@ | |||
| fastify, | |||
| isSubscription: true, | |||
| request, | |||
| socket, | |||
| socket: socket as unknown as WebSocket, | |||
There was a problem hiding this comment.
💡 Codebase verification
Subscription context needs test coverage
The type casting is correct, but there's a confirmed lack of test coverage for GraphQL subscriptions. Following the test README guidelines:
- Add black-box subscription tests that verify WebSocket connections
- Implement concurrent tests for chat message subscriptions
- Include subscription context verification in the test cases
🔗 Analysis chain
Type casting looks correct but needs test coverage.
The type casting of socket to WebSocket is necessary for proper type safety in subscription handling. However, this line is not covered by tests.
Please add test coverage for the subscription context creation. Here's a script to verify current test coverage:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find test files related to GraphQL subscriptions
echo "Searching for subscription-related test files..."
fd -e ts -e js test.*subscription test/
# Check for existing subscription context tests
echo "Checking for subscription context tests..."
rg -l "subscription.*context|context.*subscription" test/
Length of output: 320
Script:
#!/bin/bash
# Check README content
echo "=== Test README Content ==="
cat test/README.md
echo -e "\n=== GraphQL Test Files ==="
fd -e ts -e js graphql test/
echo -e "\n=== Subscription Code in Codebase ==="
rg -l "subscription" --type ts --type js src/
Length of output: 6205
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 127-127: src/routes/graphql.ts#L127
Added line #L127 was not covered by tests
|
Please make code rabbit approve your work |
|
What kind of change does this PR introduce?
Refactoring : Switched from String type to EmailAddress type in Graphql schema
Issue Number:
Fixes #2890
Snapshots/Videos:
If relevant, did you update the documentation?
Summary
Does this PR introduce a breaking change?
Checklist
CodeRabbit AI Review
Test Coverage
Other information
Have you read the contributing guide?
Summary by CodeRabbit
New Features
Improvements
Technical Updates