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

Update-with-start #1585

Merged
merged 78 commits into from
Dec 20, 2024
Merged

Update-with-start #1585

merged 78 commits into from
Dec 20, 2024

Conversation

dandavison
Copy link
Contributor

@dandavison dandavison commented Dec 11, 2024

This PR adds an API for "update-with-start", using the MultiOperation gRPC API.

The test suite is incomplete, but please feel free to review the API, implementation, and tests that are present.

The following code demonstrates the API and is taken from the early-return sample:

  const startWorkflowOperation = WithStartWorkflowOperation.create(transactionWorkflow, {
    workflowId,
    args: [transactionID],
    taskQueue: 'early-return',
    workflowIdConflictPolicy: 'FAIL',
  });

  const earlyConfirmation = await client.workflow.executeUpdateWithStart(getTransactionConfirmation, {
    startWorkflowOperation,
  });
  const wfHandle = await startWorkflowOperation.workflowHandle();
  const finalReport = await wfHandle.result();

Public API

  • New client interceptor startUpdateWithStart with interfaces WorkflowStartUpdateWithStartInput and WorkflowStartUpdateWithStartOutput
  • New class WithStartWorkflowOperation
  • WorkflowClient.executeUpdateWithStart and WorkflowClient.startUpdateWithStart

@dandavison dandavison requested a review from a team as a code owner December 11, 2024 23:41
@dandavison dandavison marked this pull request as draft December 11, 2024 23:42
@dandavison dandavison force-pushed the uws branch 3 times, most recently from 8af1806 to 1f4ad3e Compare December 12, 2024 00:02
@dandavison dandavison marked this pull request as ready for review December 12, 2024 16:16
* Thrown when it's necessary to rethrow a grpc-js ServiceError with modifications.
*/
@SymbolBasedInstanceOfError('CustomGrpcServiceError')
export class CustomGrpcServiceError extends Error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Put that error in client/src/errors.ts instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, not a fan of the name. "custom" in this context means nothing to the end user. Could we have more targetted errors? Or merge this one with client.ServiceError?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted all changes to common/src. Still not sure how to rethrow GrpcServiceError. One option seems to be just to mutate the received error and re-throw it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am:

  • Identifying WorkflowExecutionAlreadyStartedError and using that as the error if appropriate
  • Otherwise mutating the received error so that it acquires the more specific GrpcServiceError fields (code, message) as unpacked from the MultiOp error, and rethrowing the altered GrpcServiceError error

if (statusType === 'temporal.api.failure.v1.MultiOperationExecutionAborted') {
continue;
}
throw new CustomGrpcServiceError(
Copy link
Contributor

Choose a reason for hiding this comment

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

What kind of details do we have here? Could we map these statuses to error classes that we already have elsewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See above #1585 (comment)

@mjameswh
Copy link
Contributor

Please make sure to add @experimental annotations on all publicly exposed APIs introduced in this PR.


constructor(
public workflowTypeOrFunc: string | T,
public options: WorkflowStartOptions<T> & { workflowIdConflictPolicy: WorkflowIdConflictPolicy }
Copy link
Contributor

Choose a reason for hiding this comment

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

Can live with this temporarily, but we should avoid ad-hoc types in public facing APIs.

@dandavison dandavison force-pushed the uws branch 2 times, most recently from 7f7ed9e to f098dce Compare December 18, 2024 16:34
@dandavison
Copy link
Contributor Author

This is ready for another pass @mjameswh

@dandavison
Copy link
Contributor Author

One uncertainty I have is exactly how we should construct the WithStartWorkflowOperation, i.e. whether via new or via a factory function.

Copy link
Contributor

@mjameswh mjameswh left a comment

Choose a reason for hiding this comment

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

Awesome!

@dandavison dandavison merged commit dfb524e into main Dec 20, 2024
23 checks passed
@dandavison dandavison deleted the uws branch December 20, 2024 21:56
@dandavison
Copy link
Contributor Author

Thanks very much for the expert reviewing @mjameswh, as always.

mjameswh pushed a commit that referenced this pull request Dec 27, 2024
Co-authored-by: James Watkins-Harvey <james.watkinsharvey@temporal.io>
(cherry picked from commit dfb524e)
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.

2 participants