In today's meeting discussion about #1523, @jdarpinian expressed concern that an arbitrary timeout on adapter.[[current]] could result in flaky applications. In particular, even though this looks similar to real device loss (device.lost resolves), device loss during device creation logic might not be handled as well as device loss at other times, e.g. if .lost resolves before they've finished doing some necessary setup logic (this would be a badly formed application, but it's also very hard to enforce applications don't do this).
James's suggestion was that adapters be marked stale very quickly, e.g. at the end of the frame, or at the end of the task/microtask. I seriously considered this design for a while before proposing the current API, and was concerned that it could be too limiting for applications that need to do other async work near requestAdapters. On the other hand, it would be safer to start out super strict, then get laxer based on user feedback.
See also #1629, which also reduces fragility here.
In today's meeting discussion about #1523, @jdarpinian expressed concern that an arbitrary timeout on
adapter.[[current]]could result in flaky applications. In particular, even though this looks similar to real device loss (device.lostresolves), device loss during device creation logic might not be handled as well as device loss at other times, e.g. if.lostresolves before they've finished doing some necessary setup logic (this would be a badly formed application, but it's also very hard to enforce applications don't do this).James's suggestion was that adapters be marked stale very quickly, e.g. at the end of the frame, or at the end of the task/microtask. I seriously considered this design for a while before proposing the current API, and was concerned that it could be too limiting for applications that need to do other async work near requestAdapters. On the other hand, it would be safer to start out super strict, then get laxer based on user feedback.
See also #1629, which also reduces fragility here.