Conversation
| // typedCustomSerializerAdapter wraps a user-provided Serializer[any] into Serializer[T], | ||
| // handling the type assertion on decode. | ||
| type typedCustomSerializerAdapter[T any] struct { | ||
| inner Serializer[any] | ||
| } | ||
|
|
||
| func (a *typedCustomSerializerAdapter[T]) Name() string { | ||
| return a.inner.Name() | ||
| } | ||
|
|
||
| func (a *typedCustomSerializerAdapter[T]) Encode(data T) (*string, error) { | ||
| return a.inner.Encode(data) | ||
| } | ||
|
|
||
| func (a *typedCustomSerializerAdapter[T]) Decode(data *string) (T, error) { | ||
| decoded, err := a.inner.Decode(data) | ||
| if err != nil { | ||
| return *new(T), err | ||
| } | ||
| return newJSONSerializer[any]().Encode(data) | ||
| if decoded == nil { | ||
| return getNilOrZeroValue[T](), nil | ||
| } | ||
| typed, ok := decoded.(T) | ||
| if !ok { | ||
| return *new(T), fmt.Errorf("custom serializer returned %T, expected %T", decoded, *new(T)) | ||
| } | ||
| return typed, nil | ||
| } |
There was a problem hiding this comment.
Simple helper for custom serializers that performs type-assert on the user-provided serializer's output (which is any)
| type awaitWorkflowResultOutput struct { | ||
| output *string | ||
| serialization string | ||
| } |
There was a problem hiding this comment.
here and for recv and getEvent, we need to funnel to the typed, package methods, the serializer name, for decoding.
| err: nil, | ||
| startedAt: startTime, | ||
| completedAt: completedTime, | ||
| serialization: "DBOS_JSON", |
There was a problem hiding this comment.
sleep always use our default serializer, no custom/portable.
kraftp
left a comment
kraftp
left a comment
There was a problem hiding this comment.
Can we add the PL/plSQL client (just copy-paste its migration) and tests for it? That would go a long way towards testing interoperability.
More broadly, is it possible to include in the repo a test involving at least one other language, likely Python or TS? The simplest thing to do would be a TS client for a Go application. With modern Node, this is very easy, you just need a short TS script and a package.json, you don't even need to compile the TS.
| @@ -303,7 +329,15 @@ func (c *client) Send(destinationID string, message any, topic string) error { | |||
|
|
|||
| // GetEvent retrieves a key-value event from a target workflow. | |||
| func (c *client) GetEvent(targetWorkflowID, key string, timeout time.Duration) (any, error) { | |||
There was a problem hiding this comment.
pre-existing issue that I'll fix in another PR: #284
| } | ||
| b, jsonErr := json.Marshal(errData) | ||
| if jsonErr != nil { | ||
| return err.Error() // fallback to plain string |
There was a problem hiding this comment.
It's ok to have this fallback, rather than adding complex error handling to the error handling
2 participants
Add the ability to mark a workflow "portable", in which case it uses our interop format to decode its inputs, and use plain JSON encoding/decoding for other data. This supports:
RunWorkflow(which can thus be recovered/resumed on a different language.)Client
The client can do a normal enqueue with a special type to enqueue a portable workflow:
Dequeue, recovery
The code automatically flags a workflow as "portable" when detecting the portable fomat from the DB.
Direct Call
Call
RunWorkflowwithWithPortableWorkflow.