Simplify the type of MockActivityEnvironment.run

[TastyPi]

What was changed

Simplified the type of MockActivityEnvironment.run

Why?

Improves the type inference of the return type.

This example:

async function foo(): Promise<string> {
  return "foo";
}
const result = await new MockActivityEnvironment().run(foo);
result.startsWith("foo");

Does not currently compile with strict types because result is inferred as unknown instead of string. This change makes the type inference work correctly.

Checklist

1. Closes [Feature Request] Better type inference for MockActivityEnvironment.run #1710

2. How was this tested:

Made the change on my local machine and saw the red squiggly lines disappear.

3. Any docs updates needed?

I don't know, this is technically a breaking change if anyone is currently setting the type parameters.

[mjameswh]

Thanks!

At the moment, CI isn't passing. See my comments for hints on how to resolve these.

You may also add a test in test-mockactivityenv.rs using the exact code snippet you showed above. Basically:

test('MockActivityEnvironment return type is correctly inferred', async (t) => {
  async function foo(): Promise<string> {
    return 'foo';
  }
  const result = await new MockActivityEnvironment().run(foo);
  // There should be no compile time error on this line
  result.startsWith('foo');
  t.pass();
});

[TastyPi]

Thanks for the review @mjameswh, admittedly I just did a quick edit in GitHub's integrated editor, sorry for not doing it properly 😅

I've made the changes you suggested, and I think it's all good now. I tried running npm run test in my repo, but a lot of seemingly unrelated tests failed, I'm not sure if I just haven't got my local environment set up correctly or if that is expected.

[TastyPi]

@mjameswh could I get approval for this?

[mjameswh]

Very sorry for the delay.

I'm hesitant regarding the PR as it currently stands because removing the async keyword on the run function could introduce subtle differences in how the promise will be resolved, notably in regard to error handling (i.e. will a sync error result in a failed promise or an immediate error?) and to generated stack trace. I'd need to investigate a bit more to validate.

However, the team is currently working head down on a new feature which may ripple down to that specific API. For that reason, I'd prefer to wait for those other features to get in before digging more into this proposed change.

For now, I approved CI execution, so you can at least see if that resolve the build issue.