Infer Workflow Result Type from WorkflowRunOperationHandler

[VegetarianOrc]

What was changed

startWorkflow now returns WorkflowHandle<WorkflowResultType> instead of WorkflowHandle, so the handler's output type is inferred as the workflow's return type (e.g. string) rather than the workflow function type. A new workflowResultType brand on WorkflowHandle makes WorkflowHandle structurally distinct from WorkflowHandle, enabling TypeScript to catch type mismatches when explicit type params contradict the actual workflow.

Why?

Previously the WorkflowRunOperationHandler was inferring the return type to be the workflow instead of the workflow's output type. This required you to explicitly type the WorkflowRunOperationHandler in order to fulfill Nexus service contracts.

Checklist

1. How was this tested:

A test with the different combinations of typing has been added to assert compilation errors and correct inferrence.

[mjameswh]

Let's skip that comment.

[mjameswh]

The last part of this comment will be unhelpful to future readers. It puts emphasis on what will then be a former bug, actually creating confusion.

Not totally convinced of the pertinence of the first two lines, but there's not doing any harm.

Suggested change

// (e.g. string), not the workflow function type (e.g. (input: string) => Promise<string>).

[mjameswh]

Minor comments. Please fix before merging,.

[Evanthx]

Should there be unit tests for these? Or are they tested in some other way?

[bergundy]

Seems like a better structure IMHO.

Suggested change

	readonly [workflowResultType]: T;
	readonly [workflowResultType]: WorkflowResult<T>;

[VegetarianOrc]

I explored this option, but it actually conflicts with explicit typing. Including that restricts T to T extends Workflow which has knock on effects that cause any explicitly provided type parameters to also extend Workflow. For example:

// Explicit type parameters should also work correctly.
  const _explicitStringOp: nexus.OperationHandler<string, string> = new temporalnexus.WorkflowRunOperationHandler<
    string,
    string
  >(async (ctx, input) => {
    return await temporalnexus.startWorkflow(ctx, echoWorkflow, {
      args: [input],
      workflowId: 'test',
    });
  });

Instead would need to be

// Explicit type parameters should also work correctly.
  const _explicitStringOp: nexus.OperationHandler<string, string> = new temporalnexus.WorkflowRunOperationHandler<
    string,
    typeof echoWorkflow
  >(async (ctx, input) => {
    return await temporalnexus.startWorkflow(ctx, echoWorkflow, {
      args: [input],
      workflowId: 'test',
    });
  });

[VegetarianOrc]

@Evanthx

Should there be unit tests for these? Or are they tested in some other way?

There are some existing tests for the functionality of the WorkflowRunOperationHandler. In this PR I included some compile time tests to ensure that patterns expected to fail do and patterns expected to succeed do not produce compile time errors.