Closed Bug 1329069 Opened 4 years ago Closed 4 years ago
_blocklist _certificates .js | xpcshell return code: 0
59 bytes, text/x-review-board-request
Component: Sync → Firefox: Common
Product: Firefox → Cloud Services
And this is why you don't want to just let "xpcshell return code: 0" intermittent bug sit. This bug is about some "Unexpected exception Error: Request timeout. at resource://services-common/kinto-http-client.js:1866" failure which produces no other usable failure message, but now we've left autoland broken for 12.5 hours while starring permaorange caused by the patch for bug 1224528 as though it were this intermittent.
The "Request timeout." comes from the kinto-http.js library, which enforces a timeout on all requests (and it defaults to 5 seconds). This is probably too short for real users on slow connections, but probably long enough that it *usually* works in tests. However, I believe bug 1335519 and bug 1333677 are representations of the same underlying timeout occasionally being exceeded on occasional try builds. Guided by https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges#Using_magical_timeouts_to_cause_delays, I've opened https://github.com/Kinto/kinto-http.js/issues/160 to remove the underlying timeout from the kinto-http.js library, or at least stop defaulting to 5 seconds.
Comment on attachment 8843091 [details] Bug 1329069: Upgrade kinto-http-client.js to v4.0.0, https://reviewboard.mozilla.org/r/116840/#review118524
Attachment #8843091 - Flags: review?(MattN+bmo) → review+
I was waiting to ensure that this was OK based on my understanding of the necko code in https://groups.google.com/forum/#!searchin/mozilla.dev.tech.network/timeout%7Csort:date/mozilla.dev.tech.network/RJao1Fs9ZNU/Od8hzAYQAgAJ. I just spoke with mcmanus and it seems like this change is OK and won't leave lingering sockets anywhere or anything like that.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6302bbf6cc67 Upgrade kinto-http-client.js to v4.0.0, r=MattN
These failures affect 53/54 as well, but I'm guessing this isn't a great candidate for backport either. Any suggestions for what to do on the branches? :)
I guess going from 2.7.0 to 4.0.0 doesn't seem conducive to stability :) Then again, looking at it further, the two major version bumps were because of: removing this default timeout, and removing a polyfill for isomorphic-fetch, which I think we don't use here anyhow. So it might be safe to just uplift. The other thing we could do is to just extend the timeout from 5 seconds to 300 seconds (which is the natural timeout of an xpcshell test anyhow), in every place where a KintoClient is created. This might be a good change to make anyhow to improve reliability of blocklist updates and things like that, but it seems a little bit like overkill to just stop intermittent failures in 53/54. My understanding based on the OrangeFactor robot posts was that this tends to happen fewer than one time in a normal week. Is that correct? I could probably whip up a patch against 53/54 if you want, although I don't really know the process.
You need to log in before you can comment on or make changes to this bug.