feat: Backend - prompt service plumbing for error handling

[chandrasekharan-zipstack]

What

• Added support in prompt-service to log exceptions similar to backend and wrap with a valid response format
  { "code": 500 "name": "PromptServiceError" "description": "Some user-friendly message }
• Update prompt-service FE status updates to include the doc_name
• Added support in backend to parse and report this as an error, avoided suppressing errors
• MINOR: Removed some unused code in the backend

Why

• Previously there was no exception handling around prompt service calls back to the backend

How

• Passed the error message back to the backend and also pushed some updates to the FE

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

• No, no DB migrations. It doesn't introduce breaking changes to any APIs and all function definition changes were updated in places of use

Relevant Docs

• https://flask.palletsprojects.com/en/2.3.x/errorhandling/

Notes on Testing

• Tried reproducing some prompt studio errors locally and observed the error. The error handling isn't 100% yet - we include JSONs in the error message at times and we would have to beautify the response a bit more wherever possible
• Subsequent improvements require changes in the SDK and adapters which can follow in a future PR

Screenshots

Checklist

I have read and understood the Contribution Guidelines.

[sonarcloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[Deepak-Kesavan]

@chandrasekharan-zipstack In screenshot 2 and 3, we need to show the error description without JSON. Is it achievable only if we get rid of general exception catch or is it because the error happens outside our code?

[chandrasekharan-zipstack]

@chandrasekharan-zipstack In screenshot 2 and 3, we need to show the error description without JSON. Is it achievable only if we get rid of general exception catch or is it because the error happens outside our code?

@Deepak-Kesavan the error \gets triggered from

openAI -> llama_index methods -> SDK -> Prompt Service

Ideally our LLM adapter should expose the .complete() method and the error should flow as
openAI -> llama_index methods -> Adapter -> SDK -> Prompt Service

1. Now we can only implement error handling in SDK or prompt service for this and doing it in the SDK makes most sense so that it'll be applicable for all scenarios where we call an LLM.
2. We'll have to do this for every LLM provider - go through their code base's error classes and obtain a way to parse the error message (preferably their base class so that all errors can be tackled) - I'll raise an SDK PR handling it for OpenAI

[muhammad-ali-e]

LGTM