Bugzilla – Bug 8472
GUI should avoid labeling network failures as bugs
Last modified: 2009-05-26 06:36:03 UTC
You need to log in before you can comment on or make changes to this bug.
I installed os.0811-101b-rc2 as virtualbox guest in my desktop, the host is Solaris nevada build113+. When I try to intall SUNWgcc package from the GUI, it returned a GUI notification with below error messages, after a long time wait: ================================================ An unknown error occured while preparing the list of packages Please let the developers know about this problem by filing a bug at http://defect.opensolaris.org Exception value: Transfer from 'http://pkg.opensolaris.org/release' timed out. (happened 4 times) =============================================== I am sure the network works well, because I can navigate Internet through firefox.
Moving for triage.
A timeout is a transient network error, and is a completely legitimate error for the transport to return. The GUI should not be instructing users to file bugs for transport failures that are a result of transient problems in the network.
This message is coming from the general handler we have in place to handle any Exceptions we don't explicitly handle in the code. Have new Exceptions been introduced in the base transport layers J that we need to handle explicitly or are these old errors we should have handled but just never realized we needed to? What do you want us to do with transient network errors? Should we report them to the user or eat them silently?
Sorry for the slow reply. I forgot to add myself to the CC list. In the current architecture, misc.TransportException is raised for retryable transport errors that have reached a maximum and failed. This is generally due to transient failure or user misconfiguration. api_errors.InvalidDepotResponseException gets raised if the client can't contact a valid package repo when a repository is added or changed. This exception is also raised if the client is unable to contact _any_ valid repos when it starts. In this case, we might be connected to a captive portal that is redirecting our HTTP traffic until we authenticate. The ManifestRetrievalError, DatastreamRetrievalError, FileListRetrievalError, and CatalogRetrievalError are raised when the client gets permanent failures while performing network I/O. In this particular case, I would catch the TransportException separately and print an error that doesn't state that this is due to a bug. If you're curious about how the CLI copes with all of these problems, the errors are broken out into a couple of different handlers, all part of the top-level handler. More detail can be found at the end of client.py, just search for these exceptions. I think the current exception hierarchy is confusing, not all exceptions are subclasses of api_errors, and that it's generally difficult to deal with. I'm changing much of this as part of the new transport work. In that situation TransportException will become a subclass of api_errors.TransportException, and we can implement a more sensible error handling approach. We can discuss this portion more outside of bugzilla, if you'd like.
(In reply to comment #0) > I installed os.0811-101b-rc2 as virtualbox guest in my desktop, the host is > Solaris nevada build113+. The current version of the PM does catch the TransportException, could you please paste the output from the command $ pkg version To check if your version of PM does catch the TransportException or not. If it does then some underlying IPS function should throw that error when needed if not, then I will close this bug as already fixed.
The pkg upgrade worked several days ago. past the log as Michal pryc required: root@VBoxSol-OpenSolaris200811:~# pkg version 666742d60b75
Submitter provided requested information. Flipping this back to NEW.
The version you user reported this problem on was 2008.11. As the problem has been fixed since then I am marking this bug as resolved.