Allowing synchronous reads of `then` accessors on non-built-in objects

[Rich-Harris]

Hello — I found my way here via a conversation on Bluesky and hope this is the right venue in which to raise this.

From what I gather, there's an appetite to change the behaviour of thenables in a way that could impact certain (subjectively!) valid use cases. I'll articulate ours as succinctly as I can. I'm a maintainer of Svelte, which is a component framework that uses signal-based reactivity. Recently, we added the ability to await values directly inside components in a way that is coordinated by the framework:

<p>{await myQuery()}</p>

The awaited values are often thenables representing data from a server. {await myQuery()} updates when that data updates. For this to work, Svelte must know that the {await myQuery()} effect depends on the state, internal to the returned query thenable, that is updated when the data changes. By making then a getter on the object, we can read the state during the effect's execution, which builds the dependency graph that allows the framework to keep the UI in sync with the data.

You can see that in action here, or in the YouTube clip at the top of the linked Bluesky conversation.

I'll confess I don't have a firm grasp of the concerns that this proposal is addressing, or even whether use cases such as ours would be prevented by the mitigations under discussion. But I thought it worth sharing an example of the sort of thing that could break if the behaviour of await thenable were to change, in case it's relevant to future discussions. In our case we could mitigate it with more invasive code transformations (i.e. we transform await myQuery() to await readThen(myQuery()), just in case the awaited expression is the kind of thenable I described above) but this obviously has its own costs.

[mhofman]

Could you clarify the use cases you attempt to support?

It seems to me the approach you describe is brittle and breaks as soon as you refactor await myQuery() into await myProcessedQuery() for something as simple as async function myProcessedQuery() { await null; return myQuery(); }.

Or is it that the only supported awaited expressions are the ones returning synchronously a special thenable, in which case would there be a way to tie the awaited effect to the synchronous myQuery() call itself?

[Rich-Harris]

The latter — it's expected that if you read something after an indirect await, it won't be tracked. During development, it will result in a warning...

...that links to explanatory documentation. If AsyncContext existed we would use it, but in the meantime guiding people to directly reference the values they depend on covers the vast majority of cases.

(You can use any awaitable value, of course, but only the ones that read state in a then getter have the power to update themselves, as opposed to being updated.)

[jridgewell]

I'll confess I don't have a firm grasp of the concerns that this proposal is addressing, or even whether use cases such as ours would be prevented by the mitigations under discussion

Mainly, a lot of our spec internal algorithms try to handle async values, and we don't expect user code to run during this time. But, thenables break this assumptions, because the .then accessor could execute. We don't currently execute the then's function value, but the accessor is enough for several CVEs.

But I thought it worth sharing an example of the sort of thing that could break if the behaviour of await thenable were to change, in case it's relevant to future discussions.

This is exactly code that would break in some of our proposed solutions. This is a good counterpoint with in the wild code that we risk breaking.

Some of the less intesnse solutions could support this, but requires our specs to be very explicit where they want to use "secure" async vs "insecure" thenable behavior. await foo isn't one of the places we need secure behavior (hopefully), so it we could keep the existing behavior.

---

Aside, your generator async iterator. To catch the break you need to wrap your yield site with try {} finally {}:

const stream = {
  *[Symbol.asyncIterator]() {
    console.log('opening stream');

    let i = 0;
    try {
        while (i++ < 10) {
            yield `streamed ${i}`;
        }
    } finally {
        console.log('done');
    }
  }
}

The break at the control site causes an abrupt return at the point of the yield, so it's as if you were executing:

        while (i++ < 10) {
            yield `streamed ${i}`;
            // Generator is closing
            return;
        }

[bakkot]

The problem this proposal seeks to solve in its most general form is "thenables triggering user code in algorithms which don't expect it", but IIUC most of the relevant CVEs have been specifically about spec-produced values unexpectedly being thenables (through people putting .then on various prototypes). So we might well be able to solve the more narrow problem without disrupting this pattern.

The problem of await foo unexpectedly synchronously running code is also frequently a security issue for userland libraries, and it would be nice if we could change the language to avoid that issue, but security issues in browsers are much more serious.

[mgaudet]

Thank you very much for bringing this. It's good to have a use of thenables we could break directly highlighted.

Echoing gently Bakkot, my problem is mostly with values unexpectedly being thenables, caused by then on prototypes. My original pitch on the front page of the repo was directly targeted there; but in #3 Matthieu did point out there are other issues we might be able to address with the same machinery. I'm a little more skeptical now though, and if I have time before I present this coming week I'll be sure to call this out.