Feature request: Extend the Error object with an id for tracing errors

[sreiterer-rise]

Context

In the course of troubleshooting, it may be necessary to check the log entries or protocol entries of the Fachdienst to determine the cause of the error. In practice, backend services often generate unique IDs (tracing IDs) to identify client calls or conversations (e.g. B3). These IDs are printed in log entries to improve traceability.

Improvement

The API definitions for I_AccountLimit_Service, I_AccountManager_Service, I_Attachment_Service and I_ServiceInformation define an Error object (components.schemas.Error) to return an error message if an error occurs when calling one of the endpoints. It would be very helpful to extend the error object with a trace id, so that in case of an error the log entries belonging to the call can be found quickly.

[dhufnagel]

I think the property should be placed at the end of the proerty list, as the property order may be validated on some libraries. https://www.baeldung.com/jackson-annotations#3-jsonpropertyorder

It should be verified that all existing clients do not fail on unkown properties. This is the default behaviour for Jackson which is commonly used in Java clients. https://www.baeldung.com/jackson-deserialize-json-unknown-properties

[sreiterer-rise]

I think the property should be placed at the end of the proerty list, as the property order may be validated on some libraries. https://www.baeldung.com/jackson-annotations#3-jsonpropertyorder

It should be verified that all existing clients do not fail on unkown properties. This is the default behaviour for Jackson which is commonly used in Java clients. https://www.baeldung.com/jackson-deserialize-json-unknown-properties

Thanks for your feedback. I have adjusted the order of the properties. The change to the error objects is currently being coordinated in the course of regular gematik meetings.

[dhufnagel]

Any explanation why this PR was closed without merging?

[gem-uku]

manual merge to develop branche done!

[dhufnagel]

I would appreciate doing a proper merge of the Pull requests next time, as it would honor the work of the people doing the actual work by mentioning them in the contributors list. A "manual merge" is not a good solution - imho.