You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Error code and message lost in the transit for read operations #697
We recently had an issue reported by one of the stakeholders where for read operation the error code from our service backend such as 4XX is being lost in the transit to the frontend.
Here is what customer has reported when they click on an attachment in the UI where the application user does not have required access to read the attachment. For the following all the
way from our service backend to the CAP plugin the error code is preserved however after we rethrow the exception from our plugin it was lost in the transit
We ran the investigation against our plugin code and found that there is a FastODataProcessor library which looks like is not passing the error as is to the frontend
2025-10-30T12:34:34.619+05:30 ERROR 56623 --- [nio-8080-exec-2] c.s.c.a.o.v.p.FastODataProcessor : ERROR: Failed to serialize payload
com.sap.cds.services.impl.ContextualizedServiceException: You do not have the required permissions to open attachments. Please contact your administrator for access. (service 'AttachmentService$Default', event 'READ_ATTACHMENT', entity '<no entity>')
at com.sap.cds.services.impl.ServiceImpl.dispatch(ServiceImpl.java:256) ~[cds-services-impl-3.9.0.jar:na]
at com.sap.cds.services.impl.ServiceImpl.emit(ServiceImpl.java:177) ~[cds-services-impl-3.9.0.jar:na]
Just to cross check we also checked the issue against cds-feature-attachments(we did a small code change) and have observed a similar exception, here is the exception trace from the cds-feature-attachments:
2025-11-06T12:31:27.097+05:30 ERROR 21754 --- [nio-8080-exec-6] c.s.c.a.o.v.p.FastODataProcessor : ERROR: Failed to serialize payload
java.lang.RuntimeException: FAKE ERROR: Simulated attachment read failure in cds-feature-attachments
at com.sap.cds.feature.attachments.handler.applicationservice.ReadAttachmentsHandler.lambda$1(ReadAttachmentsHandler.java:110) ~[cds-feature-attachments-2.0.0-SNAPSHOT.jar:na]
at com.sap.cds.feature.attachments.handler.applicationservice.readhelper.LazyProxyInputStream.getDelegate(LazyProxyInputStream.java:63) ~[cds-feature-attachments-2.0.0-SNAPSHOT.jar:na]
at com.sap.cds.feature.attachments.handler.applicationservice.readhelper.LazyProxyInputStream.read(LazyProxyInputStream.java:40) ~[cds-feature-attachments-2.0.0-SNAPSHOT.jar:na]
at org.apache.commons.io.input.ProxyInputStream.read(ProxyInputStream.java:312) ~[commons-io-2.18.0.jar:2.18.0]
So, after multiple discussions with cap java colleagues, we found that it is not possible to propagate errors during streaming properly. Since this is an intended OData streaming behavior. The only possible solution is to check the health of the stream before delegating it. This can be done by checking the first bytes by using a buffered stream.
Problem about it is that the streams gets delegated before downloading/reading the content, since the stream gets prepared in the tables Attachment column. This causes the exception to happen already on read of the metadata.
Because SDM uses cds-feature-attachments and not cds-feature-attachments-oss we can't provide functionalities on the object store to check for health or authorization.
Ultimately, we thought that the authorization check should be done in the SDM plugin, since it has the connection to the object store.
Activity
Schmarvinius commentedon Dec 11, 2025
So, after multiple discussions with cap java colleagues, we found that it is not possible to propagate errors during streaming properly. Since this is an intended OData streaming behavior. The only possible solution is to check the health of the stream before delegating it. This can be done by checking the first bytes by using a buffered stream.
Problem about it is that the streams gets delegated before downloading/reading the content, since the stream gets prepared in the tables
Attachmentcolumn. This causes the exception to happen already on read of the metadata.Because SDM uses cds-feature-attachments and not cds-feature-attachments-oss we can't provide functionalities on the object store to check for health or authorization.
Ultimately, we thought that the authorization check should be done in the SDM plugin, since it has the connection to the object store.
yashmeet29 commentedon Feb 18, 2026
Hi @Schmarvinius, how are you ensuring that this issue never arise for applications consuming your plugin.
Regards,
Yashmeet