Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Queue broken when throwing from done() (dev-master only) #102

Closed
kelunik opened this issue Sep 13, 2017 · 6 comments
Closed

Queue broken when throwing from done() (dev-master only) #102

kelunik opened this issue Sep 13, 2017 · 6 comments
Labels
Milestone

Comments

@kelunik
Copy link

kelunik commented Sep 13, 2017

In case there's something enqueued that throws, the queue is never drained again if it wasn't empty after throwing.

<?php

require __DIR__ . "/vendor/autoload.php";

use React\Promise\FulfilledPromise;
use React\Promise\RejectedPromise;

$promiseA = new RejectedPromise(new RuntimeException("A"));

try {
    $promiseA->done(null, function ($e) {
        $promiseB = new RejectedPromise(new RuntimeException("B"));
        $promiseB->then(null, function () {
            print "OK" . PHP_EOL;
        });

        throw $e;
    });
} catch (Throwable $e) {
    // exception caught
}

$promiseC = new FulfilledPromise("C");
$promiseC->then(function () {
    // never executed

    print "C" . PHP_EOL;
});

print " -- END -- " . PHP_EOL;

It's a specially crafted example, not sure whether it will ever happen accidentally. #97 mostly solves this, but should probably also trigger fatal errors thrown from callbacks called in Queue::drain().

@jsor
Copy link
Member

jsor commented Sep 13, 2017

Thanks for reporting. I've already noticed that myself, here's a patch that fixes that: master...jsor-labs:fix-queue

The alternative approach is #97 but you're probably right, we should consider handling exceptions thrown from drain() (though, theoretically that should never happen).

@kelunik
Copy link
Author

kelunik commented Sep 13, 2017

The proposed solution would just hide a second exception if there were two, no? It's probably best to just not rethrow but to use fatalError from #97.

@jsor
Copy link
Member

jsor commented Sep 14, 2017

Yes, that was just a prototype. I stopped working on it in favor of #97.

@clue
Copy link
Member

clue commented Sep 14, 2017

I'm not sure I'm of much help here, as I'm not sure I follow, please help me understand and document this from a consumer's perspective. This ticket makes it sound like there's some major bug in this library, but as far as I can tell the issue you're seeing (or rather contriving?) is that you're throwing from the done() method which is not allowed as per the documentation?

I'm not saying that this situation couldn't be improved, but I think we should spend the time to help communicate this issue first. The title "Queue broken after one exception" is clearly misleading here (also, what "queue"?), may I ask either of you guys to change this to reflect what is actually going on here? Thank you!

@kelunik
Copy link
Author

kelunik commented Sep 14, 2017

is that you're throwing from the done() method which is not allowed as per the documentation?

While not being allowed, it might happen. And if it happens, then the entire promise library is broken.

This ticket makes it sound like there's some major bug in this library

Yes, it is, but as it's not released yet, it doesn't matter too much for now.

also, what "queue"?

The only one that exists, it's only in master: https://github.com/reactphp/promise/blob/master/src/Internal/Queue.php

@clue clue changed the title Queue broken after one exception Queue broken when throwing from done() (dev-master only) Jun 11, 2018
@clue
Copy link
Member

clue commented Apr 5, 2021

I believe this has been answered and resolved via #97, so I'm closing this for now. Please come back with more details if this problem persists and we can always reopen this 👍

@clue clue closed this as completed Apr 5, 2021
@clue clue added this to the v3.0.0 milestone Jun 8, 2022
@clue clue added the question label Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants