1
0
Fork 0
mirror of https://we.phorge.it/source/arcanist.git synced 2024-11-25 08:12:40 +01:00

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

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.)

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21198
This commit is contained in:
epriestley 2020-05-01 05:57:15 -07:00
parent 696ec3f975
commit a77cfb023d

View file

@ -41,15 +41,15 @@ abstract class Future extends Phobject {
'timeout.'));
}
if ($this->hasException()) {
throw $this->getException();
}
if (!$this->hasResult()) {
if (!$this->hasResult() && !$this->hasException()) {
$graph = new FutureIterator(array($this));
$graph->resolveAll();
}
if ($this->hasException()) {
throw $this->getException();
}
return $this->getResult();
}