-
Notifications
You must be signed in to change notification settings - Fork 3
Add Invocation Id to Module Private Data #99
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,6 +23,7 @@ public class SetFunctionInvocationContextCommand : PSCmdlet | |
{ | ||
private const string ContextKey = "OrchestrationContext"; | ||
private const string DurableClientKey = "DurableClient"; | ||
private const string InvocationIdKey = "InvocationId"; | ||
|
||
/// <summary> | ||
/// The orchestration context. | ||
|
@@ -36,6 +37,12 @@ public class SetFunctionInvocationContextCommand : PSCmdlet | |
[Parameter(Mandatory = true, ParameterSetName = DurableClientKey)] | ||
public object DurableClient { get; set; } | ||
|
||
/// <summary> | ||
/// The function invocation ID. | ||
/// </summary> | ||
[Parameter(Mandatory = true, ParameterSetName = InvocationIdKey)] | ||
public string InvocationId { get; set; } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's be careful with this parameter. Unless we make the customer invoke this cmdlet explicitly, we need to remember that whatever invokes this cmdlet may be dealing with an older SDK version that didn't have this parameter yet. So the attempt to invoke it will fail, and we need to make sure that the caller tolerates the error. Nothing special to do in this PR, but please keep this in mind. |
||
|
||
/// <summary> | ||
/// Whether or not to clear the privateData of this module. | ||
/// </summary> | ||
|
@@ -70,11 +77,16 @@ protected override void EndProcessing() | |
privateData[DurableClientKey] = DurableClient; | ||
break; | ||
|
||
case InvocationIdKey: | ||
privateData[InvocationIdKey] = InvocationId; | ||
break; | ||
|
||
default: | ||
if (Clear.IsPresent) | ||
{ | ||
privateData.Remove(ContextKey); | ||
privateData.Remove(DurableClientKey); | ||
privateData.Remove(InvocationIdKey); | ||
} | ||
break; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where would I actually call this to set the invocation id? I tried to find how
SetDurableClient()
is getting called, but didn't find it in this SDK.I looked at the internal SDK implementation and I see that it gets called in DurableController.cs
Do I need to update the Functions PowerShell worker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I believe you would need to move this method to the PowerShell worker and invoke it from there. In fact, the
SetDurableClient
andSetOrchestrationContext
methods do not make sense in this repo, and they were probably just copied over from the worker repo by mistake.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But wait, this will require us to deploy a PS worker. Perhaps we can find a way to avoid that. Two ideas:
Set-FunctionInvocationContext
explicitly from their app code. Make this a part of DT enabling instructions (at least temporary, until we are able to update the worker). Do you know if the invocation id is available in the app code?Set-FunctionInvocationContext
automatically? @andystaples, any thoughts on this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we decided that the invocation id should come from the OTel module? In this case, we can bypass the worker completely by either making the OTel module invoke
Set-FunctionInvocationContext
directly, or make the Durable SDK module invoke a command from the OTel module, whatever is more convenient. These modules don't have to take a hard dependency on each other, they will just know that cmdlets with certain names may exist, so this will be a dynamic dependency.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I seem to recall there was a reason - I recall Michael Peng telling me about this class at some point, but to be frank the reasons escape me now. My suggestion - add print statements / obvious failures in this codepath and run a few tests. If indeed it doesn't get called, then yeah just remove this.