Page MenuHomePhabricator

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

Authored by epriestley on Fri, May 1, 2:05 PM.

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
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Fri, May 1, 2:05 PM
epriestley requested review of this revision.Fri, May 1, 2:05 PM
epriestley edited the summary of this revision. (Show Details)Fri, May 1, 2:11 PM
This revision was not accepted when it landed; it landed in state Needs Review.Fri, May 1, 4:12 PM
This revision was automatically updated to reflect the committed changes.