Open kcaran opened 2 months ago
There isn't a way to guarantee order during global destruction, unfortunately. When you have objects that have other objects as properties you rely on during teardown, this can be a problem.
I thought I caught and warned about this, but maybe not. Anyways, it's another reason I built the reaper.
I'll look at this and your other PR this weekend. Thanks Keith.
I think the best way to handle this is via some kind of memoizer function to grab the LWP object (so I can worst case just make a new one) to reach out and murder playwright server processes. I'll do that.
I was going to suggest recreating the UserAgent object if it was destroyed. The UserAgent object doesn't seem complicated to me to enough to warrant a more thorough solution.
243c243
< $self->{ua} // LWP::UserAgent->new() );
---
> $self->{ua} );
The reason I allow passing of the UA is not just for testing purposes. Sometimes people need to do things like setup proxy configurations and so forth which I will have insufficient information available to be capable of reproducing.
I think to satisfy that need, I should allow the user to provide a subroutine which produces a UA as this argument. That sounds like a good feature request -- I'll reopen along those lines.
Ideally the ua parameter should also accept a UA object to preserve back-compat.
When I run tests on my macbook (perl 5.36), I get the following error at the end of the program:
I've confirmed that the LWP::UserAgent object used by the Playwright handle is being destroyed before the Playwright object itself.
Creating a new LWP::UserAgent object inside of Playwright::quit() before (or inside) the call to Playwright::Util::request() fixes the issue, but I'm not sure that is the cleanest way to solve it. But it doesn't look like there is an easy way to guarantee object destruction order.