-
Notifications
You must be signed in to change notification settings - Fork 4.9k
[Core] Wiring up rehydration token logic in data-plane #49224
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?
Conversation
public override RehydrationToken? GetRehydrationToken() | ||
{ | ||
if (_nextLinkOperation is NextLinkOperationImplementation nextLinkOperation) | ||
{ | ||
return nextLinkOperation?.GetRehydrationToken(); | ||
} | ||
|
||
return null; | ||
} |
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.
Supposedly _nextLinkOperation
will always be a NextLinkOperationImplementation
instance in data-plane. I didn't want to force a cast here to avoid throwing in unpredicted scenarios. Before this change, GetRehydrationToken
would always return null
anyway.
API change check API changes are not detected in this pull request. |
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.
Looks fine to me, but I'll ask that @JoshLove-msft and @m-nash be the authoritative approvals here, as there are generator and management plane implications.
@@ -30,6 +30,17 @@ internal ProtocolOperation(ClientDiagnostics clientDiagnostics, HttpPipeline pip | |||
public override string Id => throw new NotSupportedException(); | |||
#pragma warning restore CA1822 | |||
|
|||
/// <inheritdoc /> | |||
public override RehydrationToken? GetRehydrationToken() |
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.
I wonder if this should be added to the OperationState so that all operation types pick up the new changes.
Currently DPG libraries do not support rehydrating long-running operations. This means that, after a long-running operation has been started, users must hold their
Operation<T>
reference until its completion in order to access its final result. This can be a problem as some operations could take hours or even days to complete.Our TypeSpec code generator already supports the creation of rehydration tokens to retrieve the status of long-running operations, but the logic to do so had not been wired into our
Operation
API yet.Fixes #48594.