Store config loading errors for upstream handling

[circulon]

This PR (backend only) addresses issues encountered in #304

Currently if the parsing of the beets or beets-flask configs fails (yaml syntax, validation, etc)
the app crashes silently and fails to load the UI.
This is a poor user experience and paindul to diagnose.

In this PR we store any errors and provide them (via the socket)
back to the frontend for user examination

Leaving this as a draft as its incomplete (needs tests for backend)
Once the Tests are done this could be merged in and the frontend done separately

NOTE: I havent done much work with TypeScript so have no real idea how to capture/display/handle the "config_status"
message at app startup.

Im happy to work with anyone to move this forward.

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[circulon]

@pSpitzner @semohr
I think this is ready as a fix for the backend
is there anything else?
I updated the changelog before I realised the bot was prompting this ... Happy to remove that if required

[semohr]

Seems like mypy is not too happy yet.
I will have a closer look and eval this at the start of next week. Am a bit occupied this weekend. Maybe @pSpitzner has some spare time tho.

Feel free to ping us again if we forget about it 😨

[circulon]

@semohr @pSpitzner
ok I fixed the mypy issues and everything looks good

[semohr]

Currently if the parsing of the beets or beets-flask configs fails (yaml syntax, validation, etc)
the app crashes silently and fails to load the UI.
This is a poor user experience and paindul to diagnose.

Uhm, we do propagate raised errors to the fronted already 🥲 You can find the error handler here.

---

I dont think we need the websocket additions you added in this PR. Just converting the scanner errors into configurationerrors and re-raising them should be sufficient. Lets not introduce more complexity if not necessary.

[circulon]

Uhm, we do propagate raised errors to the fronted already 🥲 You can find the error handler here.

Apologies my description was a bit vague.
The issue is what happens if there is a YAML parser (or some other) error BEFORE the Quart app is atsrted?
Currently the if this kind of error is raised the app never gets started, so the errors can never be handled by the app at all.
Thats what this PR covers. It allows the errors to be stored (instead of raised), allowing the app to start normally, then be available when the app is ready to process them.
I hope this clarifies what im trying to cover here.

I dont think we need the websocket additions you added in this PR. Just converting the scanner errors into configurationerrors and re-raising them should be sufficient. Lets not introduce more complexity if not necessary.

thats fine I added that so the config status is available on each connect.
This would handle scenarios like editing the configs mamually while the app is running
but if you dont see that as necessary then I can remove it?

Happy to discuss further and remove that websocket "on connect" if thats unnecessary

[semohr]

Apologies my description was a bit vague.
The issue is what happens if there is a YAML parser (or some other) error BEFORE the Quart app is atsrted?
Currently the if this kind of error is raised the app never gets started, so the errors can never be handled by the app at all.
Thats what this PR covers. It allows the errors to be stored (instead of raised), allowing the app to start normally, then be available when the app is ready to process them.
I hope this clarifies what im trying to cover here.

We added the exception handling to the terminal feature flag to circumvent that exact issue (which you seem to have removed here). The web server startup should be independent of the configuration.

I think, if we should just reraise the YAML parser errors as ConfigurationError as they are sufficiently handled already. Could you try that here?
I have the feeling it should simplify all of this quite a bit.