feat(error): add feature-gated stacktrace to error received from API

[NishantJoshi00]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

This change provides a feature-gated functionality for exporting the stacktrace in the API response, for easier debugging and faster RCAs

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

This change only affects the outbound error response, adding a optional field stacktrace which is only provided when the specific feature is enabled.

Motivation and Context

How did you test it?

via. postman

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed submitted code
• I added unit tests for my changes where possible
• I added a CHANGELOG entry if applicable

[SanchithHegde]

One more request: Can we manage to un-escape the strings in the list of errors returned? It would be great if it can be done, it would improve readability by a great extent. Let me know if it involves too much effort and/or performance hits, I'll approve this PR.

[NishantJoshi00]

One more request: Can we manage to un-escape the strings in the list of errors returned? It would be great if it can be done, it would improve readability by a great extent. Let me know if it involves too much effort and/or performance hits, I'll approve this PR.

It is definitely a performance hit, but regardless there is one more concern, the context as shown in the example won't always be a json, in some cases it would just be a simple string. I should have mentioned a example for this scenario. Please refer the following:

[SanchithHegde]

It is definitely a performance hit, but regardless there is one more concern, the context as shown in the example won't always be a json, in some cases it would just be a simple string.

Even when it's a string, don't you think it would improve readability if it's un-escaped? As for the performance hit, we're expecting to enable this for debug and/or testing builds, so I believe it is acceptable?

[NishantJoshi00]

It is definitely a performance hit, but regardless there is one more concern, the context as shown in the example won't always be a json, in some cases it would just be a simple string.

Even when it's a string, don't you think it would improve readability if it's un-escaped? As for the performance hit, we're expecting to enable this for debug and/or testing builds, so I believe it is acceptable?

Hey, this side effect of having escaped characters isn't because of my implementation is handling this behaviour, it's how it is being stored. That's what causing this issue