fusion44

There's another issue which could be tackled at the same time: https://github.com/fusion44/blitz_api/issues/123 The task would be to have a coherent error response policy. To assess this will take some time.

Can you give some examples? What is a not weird format? Not sure I can do anything about the error array response... that's a FastAPI thing. Will check.

That there are multiple errors returned is a Fastapi thing. If you call an endpoint with multiple wrong query args then you'll get an error array with an error message...

Issues related to this: - https://github.com/fusion44/blitz_api/issues/148 - https://github.com/fusion44/blitz_api/issues/205 - https://github.com/fusion44/blitz_api/issues/220 - https://github.com/fusion44/blitz_api/issues/245 - https://github.com/fusion44/blitz_api/issues/247

TIL: https://www.rfc-editor.org/rfc/rfc9457.html This standard describes error handling for apis. Here's more some information: https://blog.frankel.ch/problem-details-http-apis/ Might be a good idea to implement this standard.

If something happend during fetching of the warm-up data the log files will now properly print the error: ``` Feb 25 08:27:58 python[2332042]: 2024-02-25 08:27:58 | ❌ | main.py:290 |...

They are two different problems, though.

## Proposal: A GET endpoint called `system/health` with an optional `verbose` flag. The `verbose` flag default will be false. ## Result: ```json { "healthy": true, "message": "", "subsystems": [ {...

I'll reopen this. While this is actually a CLN problem, we should display a more helpful message to the user. This means we do a bad job at detecting this...

The idea is not to enable this by default. Monitoring performance costs performance. As far as I can see there are several backend options for pyroscope including a self hosted...