-
-
Notifications
You must be signed in to change notification settings - Fork 561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(rust): change ockam_core error domain to non-static string #967
Conversation
When sending Error types over the network, static-lifetime strings can't be deserialised. This change has some implications for ockam_ffi, which now needs to allocate some memory for the C string.
Thanks for this awesome detailed write up, @spacekookie. @SanjoDeundiak when you get a chance, could you spend some time looking over this and thinking about the possible impacts? |
@spacekookie @jared-s @mrinalwadhwa @mikelodder7 |
Let's say we have Error1 with static domains and Error2 with dynamically allocated domains. Obviously Error1->Error2 conversion is simple, Error2->Error1 is impossible (well, possible, but horrible). Do these constraints good enough to build what you're trying to build @spacekookie ? |
Replacing
Considering that ockam is a highly distributed system, and errors may occur on nodes that are not the primary caller of a function chain, I feel like it is fundamental to be able to send errors that occur in operations across the network. I specifically ran into this issue because I wanted to use the
If we end up keeping the error domain as a static string, I would probably not interact with the existing error type and have a dedicated type for supervisor errors that users can encode their state into. However, I feel like this would end up being confusing to users, and severely limit the use-case of the actual error system (user code will fail if they try to send an error that the context API gives them for example). |
Merged as #1381 |
When sending Error types over the network,
'static
lifetime strings can't be deserialised. This change is required for the current ockam worker supervisor design.Change impact
This change has some obvious implications for
ockam_ffi
, and maybe others.In
ockam_ffi
the error representation can still hold a*const c_char
, but it needs to be contstructed differently. This is done viastd::ffi::Cstring
, which allocates the string in a way that C will understand. Then callinginto_raw()
returns a pointer to the location.This will leak memory if the C-calling code doesn't
free()
the string!In
no_std
settings we will need to find a way to do the equivalent thing without the standard allocator.Alternatives
I opted to use the
ockam_node::Error
type for the supervisor system because it is immediately available to users, and adds a good mechanism for namespaced error codes. There are however other approaches that we can take with this design:Separate, concrete error type
There can be a special type exposed by
ockam_core
which allows users to fill in their own error data without having to move this requirement to theockam_core::Error
.The main downside to this approach is code duplication. Based on the requirements, this type may end up being a near-identical copy of the
ockam_core::Error
type.Associative type
There can be another associated type on the
Worker
trait, meaning that users can make the supervisor error type custom to their workers.Cons:
type Foo = ...
line in the worker definition, which increases general boilerplate, even if they don't use the supervisor featureFor
no_std
settings we will have to find a way to do this without relying on the libstd CString type. But I theheapless
crate we're using probably has some way of handling this too.Anyway, this change doesn't urgently need to land, but it may be worth some thoughts with regards to how to achieve the most flexible design in this domain.