Added failing test for strange Promise.reject issue

[mattpocock]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: a0f3c61

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a0f3c61:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[ghost]

CodeSee Review Map:

Review in an interactive map

View more CodeSee Maps

Legend

[Andarist]

I think this is a "wont fix" for now. It looks like a bug. I was able to create a minimal repro case for this problem.

I think that this is what happens:

1. TS grabs the function type from this service property
2. it gets its return type and provides the contextual type (the provided string), this expands the union from like Union<T> to Union<string>
3. it recognized the function as being async so it wraps that return type in a Promise, so the type becomes Promise<Union<string>>
4. it checks if the type is a union and if it is then it would try to narrow it down, this is probably what happens for my test4, However, at this time this type is not a union so this stage is being skipped

I think that, potentially, this could even be an easy fix in TS itself -> just move the narrowing logic before wrapping the type into a Promise type. However, promises have this "auto-flattening" behavior that is recursive and maybe this is why this (unconfirmed) order of operation has been chosen. Although, it feels that this wouldn't change that much as the final "flattening"/unwrapping should happen at the end - hard to tell without examining more situations and edge cases.

[Andarist]

This is an upstream issue in TS (see here) and the fix for it awaits review here. It's not actionable on our side here.