Error propagation failure when violating Logical Quotas via iRODS HTTP API

[MarekNieslanik]

Environment:
iRODS: 5.0.2
iRODS HTTP API: 0.6.0
Plugin: irods_rule_engine_plugin_logical_quotas

We are integrating the Logical Quotas Rule Engine Plugin into our iRODS stack to track and limit collection capacity. While the plugin correctly enforces quotas at the server level (for example with icommands), the resulting error messages are not being properly propagated through the iRODS HTTP API.

When a quota constraint is violated during a write operation via the HTTP API, the API returns a generic error that does not reflect the actual cause (the quota violation).

parallel_write_init failure:
The HTTP API returns a generic INVALID_HANDLE error:
JSON response from the server

{"irods_response":{"status_code":-175000,"status_message":"INVALID_HANDLE: Could not open output stream to [/tempZone/home/rods/abcdef].\n\n"}}  // similar in HTTP API logs

However, the iRODS server logs correctly identify the issue:

"log_message":"Logical Quotas Policy Violation: Adding object exceeds maximum data size in bytes limit"

Simple write failure
A similar issue occurs with the standard write operation. The error message changes to Output stream to data object is in a bad state, but the error code remains -175000.

The main issue is that the error code (-175000) and the error messages are too generic. They are identical to errors triggered by other issues, such as a missing target collection or data object.

As a result, it is currently impossible for the client application to distinguish between a policy violation (quota exceeded) and a system error (missing path). The specific error information from the Rule Engine Plugin is lost during the transition through the HTTP API.

We would neet the HTTP API to propagate the specific error message or a unique error code provided by the Logical Quotas plugin, allowing clients to identify that a quota violation has occurred.

[MarekNieslanik]

Is there possibility that release 5.1.0 of the iRODS server would fix that?

[alanking]

Is there possibility that release 5.1.0 of the iRODS server would fix that?

I believe a change to the HTTP API would be required to get this to work, not the iRODS server. It is using the streaming library which makes failures harder to understand (because it is based on C++ I/O streams which do the same thing: https://cppreference.com/w/cpp/io.html#Stream-based_I.2FO). Although I might be wrong about some/all of that.

[korydraughn]

As @alanking pointed out, the reason for that is mostly due to the dstream library. It doesn't expose specific error codes at this time, hence the generic error code. The alternative is to replace use of dstream with the C APIs. That would expose all error codes to the client and would work for all supported versions of the iRODS server.

That effort is captured at irods/irods#8459.