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
Unreference watchers #149
Unreference watchers #149
Conversation
da4ff6c
to
2870746
Compare
2870746
to
5ae1719
Compare
Pull Request Test Coverage Report for Build 806
💛 - Coveralls |
@@ -110,6 +119,10 @@ public function should_close_connection_after_configured_amount_of_failed_reconn | |||
$closed->resolve(true); | |||
}); | |||
|
|||
// Need a watcher to keep the loop running after connection is closed. | |||
$watcher = Loop::delay(180000, function (): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is highly suspicious. I never encountered a scenario where this would be needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at all. Let me explain. In this test you're creating a connection which can't succeed and will fail with timeout, yes? This means that afterwards there is no active watcher anymore and the loop would just end immediately. But you still want to use the broken connection in order to call appendToStreamAsync
and expect it to throw InvalidOperationException
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only needed for this particular test case. In a real life application you would be okay with the loop ending immediately. But we still need the test because again in real life application the loop might stay active because of something else entirely.
@prolic Okay, I tried commenting out the So I changed Then I added the This is the command I ended up with to run the tests (mainly a note for myself):
To my surprise, the watcher causing the issue isn't from prooph but from Amphp:
Actually no. It's the Socket. |
Ah wait, nevermind. The socket created here is actually the same one that ends up in |
@prolic Ah okay. It's actually quite clear in the end. The unreferencing system works fine. What's hanging are the tests for subscriptions - namely those with a subscription still active at the end of the test. When this happens there are two options:
|
This sounds good to me. |
Okay, the tests did actually identify a bug. The issue is that if connecting to a subscription fails with AccessDenied / NotAuthenticated / MaximumSubscribersReached etc. the tests still hang. It's because the subscriptionDropped callback (which I'm using to keep track of active subscriptions) is never called. I should be able to fix this but it will still take some time. |
@prolic Okay, there is an issue with catchup subscriptions not counting the references correctly. Or rather when |
Apparently it's supposed to be called by |
This looks all good, I fixed those hanging tests for you. The problem was, that once a subscription was started, there is still some watcher active. So we need to either close the connection or stop the subscription. I did that in another branch and all tests are green again. |
@prolic I'm aware, I did the same locally. But that's not a good fix. You were right earlier that the tests should NOT hang even with all ->close() calls removed. In most cases I just need to fix the tests to close the subscription but for catch up subscription there is an actual bug in the library - there is an active watcher when there shouldn't be one. I'll fix everything else and let you know so that you can have a look at it without anything else failing. |
Can you tell me which test case is the problematic one?
…On Sat, Nov 28, 2020, 19:43 Jáchym Toušek ***@***.***> wrote:
@prolic <https://github.com/prolic> I'm aware, I did the same locally.
But that's not a good fix. You were right earlier that the tests should NOT
hang even with all ->close() calls removed. In most cases I just need to
fix the tests to close the subscription but for catch up subscription there
is an actual bug there and there is an active watcher when there shouldn't
be one. I'll fix everything else and let you know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADAJPBWDRCBEJFE3PBBXULSSF4HZANCNFSM4TOHKKBA>
.
|
Ah sorry the problem is something else... The problem isn't that dropSubscription() is not called, it's that it's called too early. It's called when Basically the subscription starts processing events before the promise returned by The problematic test, or one of them, is I pushed my other fixes. |
bf0bc49
to
c04a3de
Compare
Thanks, I'll have a look asap. |
ping @prolic |
I had a look yesterday, couldn't resolve it, I try to get some time for it these upcoming days. |
More than 2 months ago? I am really sorry @enumag |
ping @prolic :-P |
I tried 2 days ago, couldn't solve it, hopefully this weekend I have some time again. |
Yeah it's a tough one. Would have solved it myself if it was easy. |
Superseeds #140
Still need to check your comment from #117 (comment). It might be easier now with the exceptions fixed.