Repository navigation
Refinement in async function #61365
Description
🔎 Search Terms
"refinement async function"
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ. No entries matching "refinement" and nothing matching "async" or "await"
⏯ Playground Link
💻 Code
async function bar() {
return new Promise(k => setTimeout(k, 100));
}
async function foo() {
let test: null | { hello: 'world' } = null;
console.log('hi!')
setTimeout(() => {
test = { hello: 'world'}
})
await bar();
console.log('test?', test)
// running the program shows that test is `{ hello: 'world' }` but TypeScript incorrectly
// refines it to null, seemingly ignoring that there's an await which may allow the assignment to happen first
test?.hello;
}
foo();🙁 Actual behavior
Getting a type error, where TypeScript refined the type of test to null
🙂 Expected behavior
The inferred type of test should be null | { hello: 'world' }
Additional information about the issue
There seems to be an issue where TypeScript ignores awaits (and yield/yield*) when doing refinement. It seems to me that at any point after an await you can no longer assume a refinement holds true.
I understand perhaps this may be a necessary tradeoff to avoid false negatives in many cases. However since there is an explicit assignment to a let declared variable in the same function it seems a bit funny. If this is a known limitation perhaps an entry in the FAQ could be added.
Activity
MartinJohns commentedon Mar 6, 2025
Duplicate of #9998. There's even a dedicated issue template for this exact issue: https://github.com/microsoft/TypeScript/blob/main/.github/ISSUE_TEMPLATE/types-not-correct-in-with-callback.md?plain=1
philipnilsson commentedon Mar 6, 2025
Martin Johns (@MartinJohns) It's not obvious to me that the same is true for an
awaitbased on the above template.An
awaitcould be though of as desugaring intopromise.then(callback), wherecallbackis the rest of the computation, where if applying your rule of "narrowings are not respected in callbacks" you'd expect the narrowing to no longer be present, exactly the opposite of what you claim, no?Anyway, I wasn't able to find the precedent here so if this still counts as a duplicate I can close and it's up to you if you think it warrants adding to the FAQ / template.
philipnilsson commentedon Mar 6, 2025
Since there seems to be discussion here #9998 (comment) I'll just close though.