Avoid an indefinite recursion that grows the call stack when reporting the current state fails

[pcarranzav]

We used to have a recursion based on Promises and Promise.delay, which caused the promise never to resolve
so eventually the stack would be exhausted.

This fixes it by using a simpler way to check if reporting the state is in progress and using a setImmediate to
call applyState outside of the Promise chain.

Change-Type: patch
Signed-off-by: Pablo Carranza Velez pablo@resin.io

Connects to https://github.com/resin-io/hq/issues/971

Front conversations

[Page-]

@pcarranzav I'd be surprised if that setImmediate fixed it, as the promise handlers will be called in a setImmediate (or similar async construct) meaning they start with a fresh stack already

[pcarranzav]

@Page- this seems to be the only possible culprit - maybe related to petkaantonov/bluebird#1326 - my expectation is that this promise chain will be resolved and a new one will be created, clearing the stack

[pcarranzav]

(Still not sure though, investigating)

[pcarranzav]

I just ran this, left it running overnight, and woke up to an "out of memory" error:

a = Promise.resolve()
b = -> Promise.resolve()
c = -> Promise.join(a, b(), -> throw new Error()).catch( -> Promise.delay(0.00001)).finally(-> c())
d = c()

(on a resin/amd64-node:6.5-slim container)

[pcarranzav]

@Page- there seems to be a few issues in bluebird relating to the stack limit being reached in similar loops, which makes me think there must be some scenario in which such an async construct doesn't work as expected

[pcarranzav]

Also @Page-, as per this comment, storing the returned promise is an antipattern that can cause a bit of a memory bloat (it should be cleared after 4 interactions, but still...).
I'm growing more confident that this change will solve the issue.

[pcarranzav]

I wonder if this might also fix #485 - is it possible that the internal Promise bitfield changes asynchronously, so there is a non-zero time where applyState has returned and applyPromise.isPending() still returns true?
What do you think @Page- ?

Update: actually, no. That issue was something else.

[ghost]

@pcarranzav, status checks have failed for this PR. Please make appropriate changes and recommit.