dapr-sandbox / components-go-sdk Goto Github PK

Update the SDK dependencies so as to be compatible with the recently released Dapr 1.12.

For the purposes of documentation, it'd be helpful to have an "official" (preview) release/tag to reference when importing.

@mcandeia @artursouza Is this something either of you could help with?

Is your feature request related to a problem? Please describe.

If /tmp/dapr-components-sockets folder does not exist, the application will fail to start.

Describe the solution you'd like

To improve the standalone developer experience, if the /tmp/dapr-components-sockets folder does not exist, the pluggable components infrastructure should create it on startup.

Describe alternatives you've considered

Kubernetes (or even Docker Compose) deployments are unlikely to be affected as they will already have a volume mounted to /tmp/dapr-components-sockets.

dapr/dapr#6186 makes a breaking change to the state store's BulkGetResponse message. This will require updates to the SDK to match.

Is your feature request related to a problem? Please describe.

See the related dapr/dapr issue dapr/dapr#5520.

Describe the solution you'd like

The main idea is to map from statestore errors to gRPC errors accordingly to the expected gRPC status code defined at dapr runtime. It should be done at wrapper level in a fully-transparent way to support built-in components as well. The errors should be reused from components-contrib.

Describe alternatives you've considered

Additional context

The SDK currently imports 1.9.x versions of Dapr (e.g. components-contrib) dependencies. The SDK should move to the latest 1.10.x versions as they include some breaking API changes (e.g. inclusion of context in pub-sub methods) and it would be better to pull those in sooner than later.

Dapr 1.12 enabled pluggable components to create secret stores; the SDK should add support for that.

I see that pluggable component go-sdk transforms streaming into unary mode. In a question-and-answer implementation, there is a paragraph in github.com/dapr-sandbox/components-go-sdk/bindings/v1/handle.go code snippet about pendingAck:

 84                 select {
 85                 case resp := <-pendingAck:
 86                         return resp.data, resp.err
 87                 case <-ctx.Done():
 88                         return nil, ErrAckTimeout
 89                 }

If the channel pendingAck receives data timeout (default: 1s), the ACK API will directly return nil, but after executing the Send API, waiting for pendingAck will hang in/out, and the select <-ctx.Done here is to wait for the upstream to actively complete the request. and returns ErrAckTimeout. In fact, the ErrAckTimeout returned here is not suitable, it should be the upstream end of the request.

I think the correct approach should be: AcknowledgementManager.Ack API should also take ackTimeoutFlagFunc API as a return parameter, and then uniformly handle timeout, is it more appropriate? similar:

                msgID, pendingAck, cleanup, ackTimeoutFlagFunc := ackManager.Get()
                ......
                select {
                case resp := <-pendingAck:
                        return resp.data, resp.err
               case <-ackTimeoutFlagFunc(): // return Ack timeout flag.
                       return nil, ErrAckTimeout
                case <-ctx.Done():
                        return nil, nil
                }

include pubsub/bindings/state...

My main point is that when the Ack API has a processing timeout (default: 1s), the pendingAck returned by the Get API also needs to know this timeout, and then return directly without blocking waiting and relying on upstream active processing. Or should there be absolutely no packet loss?

Go SDK is available to use, but there is no documentation for it.
Use documentation in dapr-sandbox/components-dotnet-sdk as model.
I can support.

Related docs issue: dapr/docs#3189