Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First of all, I'm doing my first steps using ReactPHP, trying to use the async client. Therefore my understanding and assumptions may be wrong.
Of course, I did something wrong during my tests (tried to consume a non-existing queue) but didn't get an exception. During my research I found #39 and #36 and I thought I would try to find a solution.
From my understanding (which might be wrong), the problematic line (at least for my problem) is here.
The callback passed to
done
gets executed in the happy path and immediately rejects the deferred value.Now, the rejection causes several callbacks of the promise chain to be executed which will finally throw the exception if it is unhandled.
The thrown exception gets caught here which rejects the deferred value with the caught exception but this somehow swallows the exception.
I think this happens because there are several calls of
ClientMethods::flushWriteBuffer
in different places where the possibly returned Promise is just ignored, e.g. here.According to the docs, the callback passed to
LoopInterface::addWriteStream
is not allowed to throw an exception, so (re)throwing the exception here is no option.Instead, I tried to defer resolving/rejecting the deferred value from within the callback to a future tick of the event loop. This way, the callback still does not throw, fulfilling the requirements, and (re)throwing the exception eventually happens within the event loop where it seems to be handled correctly.
I tried to write tests for this behaviour using the example code from #36.
I think it shouldn't cause any issues since resolving/rejecting the deferred value is just delayed a little bit until the next tick of the event loop.