Skip to content
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

Provide entity support for direct grpc connections to DTS #369

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sebastianburckhardt
Copy link
Member

implements the necessary protocol conversions and configurations for providing entity support when connecting a DTS backend directly ("portable SDK").

…on history events, as used by DTS, and enable entities by default when using DTS backend.
@sebastianburckhardt sebastianburckhardt marked this pull request as ready for review January 29, 2025 23:43
@sebastianburckhardt
Copy link
Member Author

I am marking this as ready for review now that I have some tests passing.

Given that iterations are slow, I want to run a lot more tests before merging though.

@YunchuWang
Copy link
Member

LGTM

@@ -85,6 +85,12 @@ static void ConfigureSchedulerOptions(
.Configure(additionalConfig ?? (_ => { }))
.ValidateDataAnnotations();

builder.Services.AddOptions<DurableTaskClientOptions>(builder.Name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is a builder.Configure(optionsCallback) overload you can use

/// automatically converted back and forth between the old DT Core representation (JSON-encoded external events)
/// and the new protobuf representation (explicit history events), which is used by the DTS scheduler backend.
/// </summary>
public bool ConvertOrchestrationEntityEvents { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This value and InsertEntityUnlocksOnCompletion look like they are more implementation details and not a public API. I would prefer we figure out a way to make these non-public if possible. If this must be public due to different projects, then we should find a way to hide this in an .Internal namespace and add comments declaring this not meant for public consumption.

Here is an example: https://github.com/microsoft/durabletask-dotnet/blob/main/src/Abstractions/Internal/IOrchestrationSubmitter.cs

One idea would be to make these properties internal (maybe even in a sub-class to keep them together). Then add an extension method ConfigureForAzureManaged(this GrpcDurableTaskWorkerOptions options) under Microsoft.DurableTask.Worker.Grpc.Internal namespace with the comments. Then AzureManaged can call that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants