preserve reentrant header used for actors ... through the service invocation process

[aktxyz]

In the dapr doc info, they show some reentrant actor scenarios. It looks like the dapr dotnet sdk automatically creates and passes the reentrant header id ... so as long as you follow the basic scenarios described in the docs it works fine.

ActorA -> ActorA
ActorA -> ActorB -> ActorA

https://docs.dapr.io/developing-applications/building-blocks/actors/actor-reentrancy/

I am wanting a do a slightly different scenario that includes a service invocation in the process.

ActorA -> invoke some service -> ActorA

This is currently not working because the reentrant header is not automatically preserved during a service invocation.

[aktxyz]

I actually have this working with out too many changes ... that said I am sure the implementation is not up proper standards, missing scenarios, and certainly no tests ... is it worth submitting a PR or pointing to a fork to have folks take a look?

[aktxyz]

basically tuck away the reentrant header id here (before service invocation)

dotnet-sdk/src/Dapr.Client/DaprClientGrpc.cs

Line 278 in 01cdc89

// aktxyz tuck away reentrant header id before service invocation
if (Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext != null)
{
    request.Headers.TryAddWithoutValidation(Constants.ReentrancyRequestHeaderName, Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext);
}

and then on the receiving end, pluck out the reentrant header id here

dotnet-sdk/src/Dapr.AspNetCore/CloudEventsMiddleware.cs

Line 59 in 01cdc89

// aktxyz pluck out the reentrant header id after service service invocation
if (httpContext.Request.Headers.ContainsKey(Dapr.Client.Constants.ReentrancyRequestHeaderName))
{
    var daprReentrancyHeader = httpContext.Request.Headers[Dapr.Client.Constants.ReentrancyRequestHeaderName];
    Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext = daprReentrancyHeader;
}

This seems to work fine ... so good enough to keep working ... would love to see support for this added in a proper way sometime in the future.

[aktxyz]

Does anyone on the DAPR team have any thoughts on this ... I think maintaining the reentrant header id across service invocations is a good thing !

[WhitWaldo]

I understand that this functionality is technical feasible. However, it would be really helpful if you could provide more details about the specific scenario where this shortcoming is blocking you and your project. This information would strengthen the case for addressing this issue, rather than it being seen as an interesting aspect of an otherwise incomplete but usable feature.

[aktxyz]

basically I have a case where I do something like this ...

ActorA -> invoke some service -> ActorA

• ActorA receives a request
• ActorA pubs out an async message (service invoke), which is picked up by multiple services listening for this message type
• when each service completes it's task, it sends results back to ActorA via a message

so basically

ActorA -> invoke some services (reentrant ID lost here) -> ActorA

[WhitWaldo]

Why do you need re-entrancy for this scenario? Why not simply call the actor anew with the message results?