fix: propogate errors to cas [JAR-9409, JAR-9415]

[andrewwan-uipath]

https://uipath.atlassian.net/browse/JAR-9409
https://uipath.atlassian.net/browse/JAR-9415
Related to this PR: UiPath/uipath-python#1421

[maxduu]

Nice, what does licensing errors look like on UI? Does it match the Temporal behavior?

Also, we've been using error-ids here and we should port them over if possible? This way our frontend can look at the error-id and render things consistently between Temporal / UR backends. If you could look at the current error-ids we emit and check if their usages can be ported over for UR, would be great.

[andrewwan-uipath]

Nice, what does licensing errors look like on UI? Does it match the Temporal behavior?

Also, we've been using error-ids here and we should port them over if possible? This way our frontend can look at the error-id and render things consistently between Temporal / UR backends. If you could look at the current error-ids we emit and check if their usages can be ported over for UR, would be great.

Looks like we might need to make some code changes in uipath-langchain. It doesn't handle errors correctly it seems like. Currently it will just show the raw error messages. We should be able to port over the errors id except for the max steps reached one. Doesn't seem like we have that logic implemented.

[maxduu]

Thanks @andrewwan-uipath. Feel free to make a ticket for the max-steps as well with label bugbash

[andrewwan-uipath]

Thanks @andrewwan-uipath. Feel free to make a ticket for the max-steps as well with label bugbash

oh actually, I did some more digging and we do have max iterations

[cristipufu]

These mappings (CAS-specific protocol concerns) should be a part of uipath-python (chat bridge protocol implementation).

Use this layer to catch exceptions and emit error events, and then map the errors with CAS specific logic/error codes here https://github.com/UiPath/uipath-python/blob/main/packages/uipath/src/uipath/_cli/_chat/_bridge.py#L28

[cristipufu]

We should change the signature to accept an Exception directly instead of decomposed primitives: error_id and message are always derived from an exception at the call site anyway. Just let the protocol implementation decide what to do with the exception.

We have other apps that use these contracts, that might want to handle this differently

[cristipufu]

you need to increment the major version 0.10.0 (adding a new protocol method is a breaking change)