Page MenuHomePhabricator

When a proxy future wraps a future which throws an exception, resolve with an exception
ClosedPublic

Authored by epriestley on May 1 2020, 2:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Oct 31, 10:43 AM
Unknown Object (File)
Oct 18 2024, 6:58 PM
Unknown Object (File)
Oct 17 2024, 6:17 AM
Unknown Object (File)
Oct 10 2024, 11:58 PM
Unknown Object (File)
Sep 4 2024, 11:20 PM
Unknown Object (File)
Sep 3 2024, 4:06 PM
Unknown Object (File)
Aug 26 2024, 1:32 AM
Unknown Object (File)
Jul 30 2024, 8:58 AM
Subscribers
None

Details

Summary

Ref T13528. When you call $future->resolve(), we currently guarantee it is resolved by calling FutureIterator->resolveAll().

resolveAll() does not actually "resolve()" futures: it guarantees that they are ready to "resolve()", but does not actually call "resolve()".

In particular, this means it does not throw exceptions.

This can lead to a case where a Future has "resolve()" called directly (e.g., via a FutureProxy), uses "FutureIterator" to resolve itself, throws an exception inside "FutureIterator", the exception is captured and attached to the Futuer, then the outer future tries to access results. This fails since it's out-of-order.

This can happen in practice with syntax highlighting futures, which may proxy pygments futures.

Instead, "resolveAll()" before testing for exaceptions.

Test Plan
  • Locally, tried to highlight a Paste with an unrecognized lexer extension using Pygments.
  • Before patch: fatal when trying to access results of a Future with no results (because it has an exception instead).
  • After patch: resolution throws the held exception properly.
  • (See also next change.)

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable