fix(contrib/99designs/gqlgen): fix panic on empty response from response handler#3728
Conversation
…andler The response object was not checked for nil before accessing it in `gqlTracer.InterceptOperation`. I've added a nil check before checking the length to prevent a panic.
|
/merge |
|
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
devflow unqueued this merge request: It did not become mergeable within the expected time |
|
/merge |
|
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
The expected merge time in
|
The response object was not checked for nil before accessing it in
gqlTracer.InterceptOperation. I've added a nil check before checking the length to prevent a panic.What does this PR do?
Fixes a nil pointer dereference panic in the GraphQL tracer when the response handler returns a nil response. The fix adds a nil check before accessing
response.Errorsto prevent the panic from occurring.Motivation
This panic was encountered in production when GraphQL operations were timing out or being cancelled, causing the response handler to return
nil. The tracer would then attempt to accessresponse.Errorswithout checking ifresponsewas nil first, leading to a runtime panic.The issue occurs specifically in scenarios where:
nildue to context cancellationThis fix ensures the tracer gracefully handles nil responses by checking
response != nilbefore attempting to access itsErrorsfield, consistent with the nil checking pattern used elsewhere in the same function.