What happens if you don't attach a .then() to a hit-test promise until much later

[lincolnfrog]

A developer could potentially do something like this:

var promise = xrSession.requestHitTest(...);
window.setTimeout(() => { promise.then(...); }, 99999);

What happens here? The result is totally invalid at the point when it resolves. Can the promise be invalidated after the RAF for which it is valid is issued? This gets especially dangerous if we add the XRFrame object to the promise resolution of hit-test, as that frame will be potentially invalid at the late-attached "then".

[jsantell]

Promises can't change from a fulfilled to a rejected state; I don't know if there's anything the implementation should do to handle this if wanting to retain stale results. What are the downsides? Are there any implications on the implementation side of things of retaining a stale XRFrame and XRHitResult?

[lincolnfrog]

According to @toji XRFrames are only valid while that frame is active and should be considered invalid as soon as the next frame starts processing (and may actually need to be marked as such in case people try to store them). The concern is if you late-attach a .then(), you will basically be "storing" an old XRFrame

[jsantell]

@lincolnfrog is that any different than a developer retaining an XRFrame in other contexts?

onXRFrame(time, frame) {
  this.lastFrame = frame;
}

That is to say, this behavior isn't hit-test-specific, and since promise resolution timing is defined in this spec as resolving on the subsequent frame, and only being valid for that frame, should by handled by the WebXR Device API with regard to validity or side effects of a stale frame -- AFAICT this isn't explicit in the spec yet (e.g. does getting a pose from a stale frame throw?)

[bialpio]

Closing - no longer applicable - we are not currently planning on adding a promise-based API.