Unexpected GOOPDATE_E_NON_BLOCKING_CALL_PENDING in UMA top ten for GoogleUpdate.ErrorHresult |
||||
Issue descriptionThe 5th top UMA error for GoogleUpdate.ErrorHresult is -1606219753 == GOOPDATE_E_NON_BLOCKING_CALL_PENDING. GOOPDATE_E_NON_BLOCKING_CALL_PENDING is returned if a call comes in when another call is already pending. For example, CheckForUpdate is in progress, and in the middle of GoogleUpdate doing that check, an Install call comes in from the same client.
,
Jul 7 2016
,
Jul 14 2016
google_update_win.cc polls GU for status after calling checkForUpdate. It isn't supposed to call install() until it gets STATE_UPDATE_AVAILABLE. Are there any other combinations for which it would return that error? Which calls into GU could return that error?
,
Jul 14 2016
Could it be multiple tabs open to chrome://chrome that could be causing this?
,
Jul 15 2016
Anything's possible, but I don't think so. Multiple tabs should share the same driver instance that calls into GU as of Chrome 48 -- each is an observer of the same polling process.
,
Jul 15 2016
+pmonette who implemented the thing I just mentioned.
,
Aug 1 2016
It looks like GOOPDATE_E_NON_BLOCKING_CALL_PENDING is expected if bundle->install() is called twice in a row. Is it possible that IAppWeb::get_currentState still reports STATE_UPDATE_AVAILABLE shortly after bundle->install() is called?
,
Sep 6 2016
,
Sep 6 2016
BTW: I think the answer to the above question is "no." I still don't know how this error could be cropping up. |
||||
►
Sign in to add a comment |
||||
Comment 1 by chrisha@chromium.org
, Jul 7 2016