Criticité : 🟠 Moyenne (Mauvais code HTTP côté API, erreur non gérée côté Frontend polluant Rollbar)
Occurrences (sur 28 j) : ~21 occurrences remontées sur Rollbar
Description of the issue
When the Web App sends a request to enable telemetry or break-in monitoring (e.g., POST /telemetry-config/break-in-monitoring/{vin}/enable), if the backend fails to push the config to the Tesla API (e.g. because the vehicle is asleep or a timeout occurs), the backend returns a JSON payload { success: false, message: 'Failed to push telemetry configuration to Tesla' } but with an HTTP 201 Created status code.
Because the status is 201, the ApiClient on the frontend considers the request successful. Then, in the React Query mutation (use-vehicles-query.ts), the code manually checks if (!result.success) and executes a throw new Error(...). This unhandled JS error is caught by Rollbar as an application crash.
Expected Behavior
- Backend: If the operation fails, the controller or service should throw an appropriate
HttpException (e.g. 400 Bad Request or 502 Bad Gateway) instead of returning a 201 status code.
- Frontend: Rely on the
ApiClient's standard error handling for failed HTTP statuses, and ensure React Query properly surfaces this as a Toast notification to the user without letting it bubble up as an unhandled exception to Rollbar.
Logs (Rollbar)
Error: Failed to push telemetry configuration to Tesla
at [anonymous](https://www.sentryguard.org/_next/static/chunks/18dw~ggm8oci5.js)
Criticité : 🟠 Moyenne (Mauvais code HTTP côté API, erreur non gérée côté Frontend polluant Rollbar)
Occurrences (sur 28 j) : ~21 occurrences remontées sur Rollbar
Description of the issue
When the Web App sends a request to enable telemetry or break-in monitoring (e.g.,
POST /telemetry-config/break-in-monitoring/{vin}/enable), if the backend fails to push the config to the Tesla API (e.g. because the vehicle is asleep or a timeout occurs), the backend returns a JSON payload{ success: false, message: 'Failed to push telemetry configuration to Tesla' }but with an HTTP 201 Created status code.Because the status is 201, the
ApiClienton the frontend considers the request successful. Then, in the React Query mutation (use-vehicles-query.ts), the code manually checksif (!result.success)and executes athrow new Error(...). This unhandled JS error is caught by Rollbar as an application crash.Expected Behavior
HttpException(e.g.400 Bad Requestor502 Bad Gateway) instead of returning a 201 status code.ApiClient's standard error handling for failed HTTP statuses, and ensure React Query properly surfaces this as a Toast notification to the user without letting it bubble up as an unhandled exception to Rollbar.Logs (Rollbar)