Repository navigation
Refs #BAC-530: Accept Date for DateTime and give GraphqlRails models the query context - #7
Merged
povilasjurcys merged 4 commits intoOct 20, 2026
Conversation
…ls the query context DateTime and Date fields are checked through coerce_result, so a Date in a DateTime field passes as it does at runtime. be_successful_graphql_request calls GraphqlRails model fields inside with_graphql_context(request context), so decorators reading graphql_context no longer fail only in the matcher. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nd cover nested fields graphql-ruby leaves graphql_context unset when a GraphqlRails model sits behind a plain GraphQL type, so the matcher must too. Pins the context reaching list items, records that aren't models, and the date scalars' edge values. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…as at runtime GraphqlRails' resolvers set it for any object that responds to with_graphql_context, so a subclass returned where its parent type is declared gets it too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
povilasjurcys
force-pushed
the
feature/BAC-530-date-scalars-and-graphql-context
branch
from
October 19, 2026 07:07
3360a7a to
c56e829
Compare
There was a problem hiding this comment.
🟡 Changes recommended
The limited request context introduces matcher failures for fields using graphql_context&.dig.
1 open issue
What changed in this PR
Aligns date validation with GraphQL serialization and passes request context to GraphqlRails model fields.
Changes:
- Validates date scalars through
coerce_result. - Propagates optional context through field validation.
- Adds regression specs and changelog entries.
| File | Description |
|---|---|
| spec/lib/rspec_extra_matchers/graphql_matchers/type_matcher_spec.rb | Covers date coercion and model context behavior. |
| spec/lib/rspec_extra_matchers/graphql_matchers/successful_graphql_controller_response_matcher_spec.rb | Tests request-context forwarding. |
| lib/rspec_extra_matchers/graphql_matchers/type_matcher.rb | Accepts and forwards optional context. |
| lib/rspec_extra_matchers/graphql_matchers/successful_graphql_controller_response_matcher.rb | Retrieves context from supported responses. |
| lib/rspec_extra_matchers/graphql_matchers/assert_type_and_value.rb | Coerces date scalars and scopes model context. |
| CHANGELOG.md | Documents validation and context changes. |
Review effort: Balanced
…the query context GraphQL resolves an interface to the record's object type before calling its fields, so a GraphqlRails model behind an interface field reads graphql_context at runtime. Check that type instead of the interface. Also cover a non-model record under a GraphqlRails type. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

What's the reason for this feature?
Currently,
be_successful_graphql_requestreports two false positives in controller specs:DateTime!field returning aDatefails, though GraphQL serializes it correctly.graphql_contextraises, because the matcher never sets it (e.g., in shift decorators).This PR:
ISO8601DateTimeandISO8601Datethroughcoerce_result. The other built-in scalars keep their class lists, since theircoerce_resultaccepts almost anything.response.context) down to field calls. A field runs insidewith_graphql_contextwhen its type is one GraphqlRails built, matching GraphqlRails' resolver behavior. graphql-ruby calls stay onNullContext.Reviewers should know:
Datefields now accept anythingDate.parse(to_s)accepts, such as20240101, as GraphQL does. This is documented in the CHANGELOG.[]/fetch/key?/to_h, so decorators that callgraphql_context&.dig(...)will fail the matcher if the context doesn't support deep navigation. Other open items: the CHANGELOG needs the graphql_rails version once released, no spec pins therespond_to?(:with_graphql_context)guard yet, and the newgraphql_context:keyword belongs under "Added".response.context), fields run without a context, as before.Testing done: gem suite, 122 examples, 0 failures. Validated with updated gem branches in an application test suite where date fields pass the matcher and decorators resolve
graphql_contextcorrectly with the request context (and fail without it).