You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If users provide invalid data there are some situations where the logs in Infrahub are excessive. An example is if you try to create a BuiltinTag called "red" and this tag already exists.
The user will be informed that the tag exists and everything seems fine from the users point of view.
However in the logs we get a critical error:
14:34:05.297|CRITICAL|infrahub.graphql- {'exc_info': ValueError('An object already exist with this value: name: red at name'), 'event': 'Unhandled exception occurred in resolvers', 'request_id': '16ab53b810eb45f6aa07c6627d3e55ec', 'app': 'infrahub.api', 'worker': '36af3e7d-5c7b-432b-b92d-05d9e1fd890b', 'timestamp': '2024-10-09T12:34:05.297274Z', 'logger': 'infrahub.graphql', 'level': 'critical'}
This could be that we're reraising an error we've already defined as the internal ValueError which we then don't do anything about.
Another example is if the user sends in an invalid query:
In the above query we are missing the last closing bracket and when sent into Infrahub even the error message returned looks off:
{
"errors": [
{
"message": "Failed to fetch",
"stack": "TypeError: Failed to fetch\n at http://localhost:8080/src/pages/graphql/index.tsx:31:22\n at http://localhost:8080/node_modules/.vite/deps/chunk-QUUSDRZS.js?v=62db7a3e:14302:33\n at onClick (http://localhost:8080/node_modules/.vite/deps/chunk-QUUSDRZS.js?v=62db7a3e:16791:19)\n at overrideProps.<computed> (http://localhost:8080/node_modules/.vite/deps/chunk-Y72ESYVM.js?v=62db7a3e:76:9)\n at HTMLUnknownElement.callCallback2 (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:3674:22)\n at Object.invokeGuardedCallbackDev (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:3699:24)\n at invokeGuardedCallback (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:3733:39)\n at invokeGuardedCallbackAndCatchFirstError (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:3736:33)\n at executeDispatch (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:7014:11)\n at processDispatchQueueItemsInOrder (http://localhost:8080/node_modules/.vite/deps/chunk-ZFKBY7OL.js?v=62db7a3e:7034:15)"
}
]
}
Here the expectation would be a cleaner log message.
Also within the actual Infrahub logs it's very verbose. We might have an info log for reference if a wrong query comes it, or nothing at all. It should be treated as a user error and reported back in a friendly way.
Component
API Server / GraphQL
Task Description
If users provide invalid data there are some situations where the logs in Infrahub are excessive. An example is if you try to create a BuiltinTag called "red" and this tag already exists.
The user will be informed that the tag exists and everything seems fine from the users point of view.
However in the logs we get a critical error:
This could be that we're reraising an error we've already defined as the internal
ValueError
which we then don't do anything about.Another example is if the user sends in an invalid query:
In the above query we are missing the last closing bracket and when sent into Infrahub even the error message returned looks off:
Here the expectation would be a cleaner log message.
Also within the actual Infrahub logs it's very verbose. We might have an info log for reference if a wrong query comes it, or nothing at all. It should be treated as a user error and reported back in a friendly way.
The text was updated successfully, but these errors were encountered: