Add tests to validation behaviour of graphql-transport-ws subscriptions#3671
Add tests to validation behaviour of graphql-transport-ws subscriptions#3671kristjanvalur wants to merge 25 commits intostrawberry-graphql:mainfrom
Conversation
…le." This reverts commit 6198007.
f1f9efa to
c4d0b05
Compare
CodSpeed Performance ReportMerging #3671 will not alter performanceComparing Summary
|
Reviewer's Guide by SourceryThis pull request adds new tests to validate the behavior of GraphQL Transport WebSocket (WS) subscriptions and queries. It focuses on ensuring validation runs on a worker task, error handling, and validation checks for both queries and subscriptions. The changes reveal a discrepancy in how validation errors are handled between queries and subscriptions. Sequence diagram for validation error handling in GraphQL WSsequenceDiagram
participant Client
participant Server
Client->>Server: Send query { conditionalFail(fail:true) }
Server-->>Client: ErrorMessage { "type": "error", "id": "sub1", "message": "failed after sleep None" }
Client->>Server: Send subscription { conditionalFail(fail:true) }
Server-->>Client: ErrorMessage { "type": "error", "id": "sub1", "message": "failed after sleep None" }
Class diagram for ConditionalFailPermission and Schema changesclassDiagram
class ConditionalFailPermission {
+string message
+bool has_permission(source, info, **kwargs)
+float sleep
+bool fail
}
class Query {
+string conditional_fail(sleep, fail)
}
class Subscription {
+string conditional_fail(sleep, fail)
}
Query --> ConditionalFailPermission
Subscription --> ConditionalFailPermission
note for ConditionalFailPermission "Handles permission with optional sleep and fail parameters"
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey @kristjanvalur - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟡 Testing: 1 issue found
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| async def test_validation_query(ws: WebSocketClient): | ||
| """ | ||
| Test validation for query | ||
| """ | ||
| await ws.send_json( | ||
| SubscribeMessage( | ||
| id="sub1", | ||
| payload=SubscribeMessagePayload( | ||
| query="query { conditionalFail(fail:true) }" | ||
| ), |
There was a problem hiding this comment.
issue (testing): Inconsistency in error handling between queries and subscriptions
As noted in the PR description, there's a discrepancy in how validation errors are handled for queries vs. subscriptions. This test is failing because it expects an ErrorMessage, but receives a NextMessage instead. Consider updating the implementation to handle validation errors consistently across queries and subscriptions.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3671 +/- ##
===========================================
- Coverage 97.01% 10.99% -86.02%
===========================================
Files 503 454 -49
Lines 33458 29078 -4380
Branches 5618 1659 -3959
===========================================
- Hits 32460 3198 -29262
- Misses 792 25719 +24927
+ Partials 206 161 -45 |
Description
Additional tests for queries and subscriptions over
graphql_transport_wsprotocol.Note:
The tests uncover a discrepancy regarding the validation handling for queries vs. subscriptions. This is a behavior change since the recent changes in the subscriptions code.
When a subscription fails during validation, an
errormessage is sent. But if the same method is a single result (query), anextmessage is sent.Ideally, validation should be handled the same for both. The "errors" field of the
ExecutionResultshould indicate an error during execution, not pre-validation.The failing test is
test_validation_querywhiletest_validation_subscriptionsucceeds.The PR is not complete, it serves to illustrate a problem, I am open to suggestions. Accept the behaviour? Make validation return a
PreExecutionError? Add some other special handling?Types of Changes
Issues Fixed or Closed by This PR
Checklist