How to properly dispose disconnected remote instance

[DimitarKrastev]

In the usual case it is kind of straight forward how to deal with puppeteer sharp IBrowser. Tabs and browsers that are no longer needed should be disposed and the browsers we want to keep for later should only be disconnected.

The question however is what should be done once a remote browser dies during tab creation (maybe remote host went down).

On one hand standard coding practice is to dispose all disposable resources used in the code.
On the other, the documentation for "Disconnect()" method says "Disconnects Puppeteer from the browser, but leaves the process running. After calling Disconnect, the browser object is considered disposed and cannot be used anymore"

So if a remote browser gets disconnected because of an exception (but not by calling Disconnect() explicitly), should we still call Dispose() or skip it?

The reason I am asking is is that today we experienced an outage on some of our browser servers which caused an Unhandled exception in our .Net 7 application crashing with Semaphore already disposed exception.

I started troubleshooting the whole lifecycle of IBrowser objects and so far this is the only clue I have. If the object was already disposed because of the disconnect exception, later on when we call Dispose() on the object might explain why we got the exception.

Thanks.

[kblok]

@DimitarKrastev That's a bug. We should fix it.

[jnyrup]

This sounds related to the guard added in #2095 where TaskQueue.DisposeAsyncCore could throw an ObjectDisposedException if its semaphore had already been disposed.