Conversation
| serialization: string | null, | ||
| serializer: DBOSSerializer, | ||
| ): Error { | ||
| if (serialization === DBOSPortableJSON.name()) { |
There was a problem hiding this comment.
How does this work? I might be missing something, but errors won't be portable-JSON-serializable.
There was a problem hiding this comment.
Correct, we are replacing errors with an error with a portable surface area containing:
Message - (seems to exist universally)
Name - class name (commonly exists)
Code - seems common enough to keep
Data - Where everything else goes, up to the app
This pattern is what is used in other frameworks that do similar things.
If you just want an error for human consumption / to know if it went wrong, this will be OK. If you want to be able to handle the error exactly as thrown, you need to get your function to throw/catch an error of this shape. (Your whole function prototype has tighter restrictions than that of the native language serializer, this compromise is inevitable when making portable calls.)
There is currently one loose end with that that I intend to fix ... reinterpreting whatever is thrown from a WF into this error within a direct TS call that does not use the handle.
There was a problem hiding this comment.
It turns out that errors aren't serializable with any fidelity at all in JS, and we have a small hole in the SDK already.
2 participants
Support for enqueuing and interacting with workflows across languages. Centers on use of simple JSON in the workflow_status and other tables, adds a column to distinguish the serialization format.
Portable enqueue can be done via
DBOSClient, DBOS., and direct INSERT into the WF status table.startWorkflowwill also start a workflow with portable serialization format, if it is requested, or if the registration indicates such. Portable WFs will set their return value, events, and stream writes in portable format, but this can be overridden when callingDBOS.setEvent,DBOS.writeStream, andDBOS.send, allowing full interaction across languages.Obviously, this tightens the rules about arguments and return values... for portable workflows the rule is "must be serializable as plain JSON" not "must be serializable with SuperJSON".