Map unhappy paths in application

[chriswilty]

Make list of all the unhappy paths of app. Determine which paths are handled already. Priotitise the remaining paths according to how likely they are to occur, and how much damage they will cause if unhandled. Write tickets to implement

Unhappy paths:

• OpenAI rate limiting Show rate limiting error message to the user #493
• more....

[gsproston-scottlogic]

May want an error code system to be able to show specific backend errors to the users.
After we identify the unhappy paths, we can assign error codes to some of them.

[gsproston-scottlogic]

For rate limiting:

Turns out the open AI API has some rate limiting. When you hit your limit, all the user can see in the front end is the generic "couldn't get reply from chatGPT" or similar. I think we should give a more descriptive error message, so that user knows to leave it a minute before trying again.

This could use some UI input, but we could implement our best guess in the meantime.

Clues:
we have a try/catch block in handleChatError() in backend/src/router.ts. When we hit our rate limit, we enter the catch block, and the error object includes status: 429 and statusText: "Too Many Requests".