05:29:43 INFO - [4073] WARNING: unexpected progress values - is server exceeding content length?: file /builds/slave/gum-osx64-d-000000000000000000/build/netwerk/protocol/http/nsHttpChannel.cpp, line 5346 if (progress > progressMax) NS_WARNING("unexpected progress values - " "is server exceeding content length?"); TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_range_requests.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | request reports itself as not pending from onDataAvailable! - See following stack: TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Error in onDataAvailable: 2147500036 - See following stack: TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Failed to load URL: 80004004 - See following stack: TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Error in onStopRequest: 2147500036 - See following stack: Return code: 1 https://tbpl.mozilla.org/php/getParsedLog.php?id=38142398&tree=Gum https://hg.mozilla.org/projects/gum/rev/fcaac8e0137a

Could not reproduce locally after some 2000 iterations.

The most common way I've seen this error is from bug 748117. Any chance we could somehow be missing a Content-Type here? We could also just fix 748117 and see if it makes the orange go away (although occasionally omitting the Content-type would probably be a symptom of an underlying real bug).

I think this is something else. I think we deliver partial data from the cache and then do a full request to the server (or the server doesn't respond to the range request with 206 but with 200 and a full response or with a wrong 206.)** Maybe it's just about checking the test doesn't suffer the usual assumption that requests come to the server in the same order as made by the client. Since this is very low rate I tend to move this to after-enable phase. ** This logic is there becuase of the concurrent read/write - when writer is interrupted (e.g. by cancelation from upper levels, e.g. docshell) request reading the entry in parallel (concurrently) needs to make a range request for the rest of the data - actually behave as the cache date were partial.

Cannot reproduce this at all. Moving to the after-enable phase.

- thanks a race condition it sometimes happens that the cache entry output stream is not closed before the second request for the same URL is made, thus the concurrent partial read logic is engaged - we mistakenly set mIsPending flag to false before the channel makes its range request for the rest of the data

see comment 6

Comment on attachment 8423840 [details] [diff] [review] v1 https://hg.mozilla.org/integration/mozilla-inbound/rev/38e5a78e407f

This patch had the misfortune of landing in the middle of a large bustage pileup on inbound that led to me having to revert to a last-good cset in lieu of waiting 3-4 hours for green instead. Unfortunately, that means this was backed out along with the others. If this was confirmed green on Try, it can re-land at your convenience. https://hg.mozilla.org/integration/mozilla-inbound/rev/eb2a6f7785a2