api | DEBUG [2022-01-02 22:27:21.910 +0000] (graphql-server): GraphQL execution started: GetEventDataQuery
api | DEBUG [2022-01-02 22:27:21.968 +0000]: [events.js] db.event.findUnique: {
api | "message": "Access Denied, Or Record Not Found",
api | "extensions": {
api | "code": "409"
api | }
api | }
api | ERROR [2022-01-02 22:27:21.974 +0000] (graphql-server): Access Denied, Or Record Not Found
api | error: {
api | "message": "Access Denied, Or Record Not Found",
api | "locations": [
api | {
api | "line": 2,
api | "column": 3
api | }
api | ],
api | "path": [
api | "event"
api | ],
api | "extensions": {
api | "code": "409"
api | }
api | }
api | DEBUG [2022-01-02 22:27:21.975 +0000] (graphql-server): GraphQL execution completed: GetEventDataQuery
Well, ever go to a site and get a “Unable to connect to Microsoft SQL Server, php error line 1234: ODBC 2.0 Connection issue timeout expired” (paraphrasing :)).
I just learned seem useful stuffs about your server - using php, connecting to SQL server and whatnot.
Here’s the rationale for masking:
In many GraphQL servers, when an error is thrown, the details of that error are leaked to the outside world. The error and its message are then returned in the response and a client might reveal those errors in logs or even render the message to the user. You could potentially leak sensitive or other information about your app you don’t want to share—such as database connection failures or even the presence of certain fields.
Redwood is here to help!
Redwood prevents leaking sensitive error-stack information out-of-the-box for unexpected errors. If an error that isn’t one of Redwood’s GraphQL Errors or isn’t based on a GraphQLError is thrown:
The original error and its message will be logged using the defined GraphQL logger, so you’ll know what went wrong
A default message “Something went wrong” will replace the error message in the response (Note: you can customize this message)
Therefore, as a best practice, those stack traces and any exception errors raised by Prisma or a third-party api or something in a service is shielded from the end user.
Also, the Dev Console for the api sever will always show the complete error with stack trace – and this original error will also be logged as an error in Production to your logger destination.