[Webkit-unassigned] [Bug 147783] Expand network cache tests to cover memory cache behavior

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 7 10:09:30 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=147783

--- Comment #3 from Antti Koivisto <koivisto at iki.fi> ---
> What makes these tests reliable and repeatable? Could these resources get
> purged randomly? I just checked, and we have quite a few existing cache
> tests that are flaky:
> 
> https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.
> html#showAllRuns=true&tests=cache%2F

If I understand these correctly http/tests/cache/disk-cache/ tests (which this is about) look stable on Apple platforms newer than Mavericks. In any case thit shouldn't make these tests any more or less stable.

> > Source/WebCore/loader/cache/CachedRawResource.cpp:144
> > +        if (validationInProgress())
> > +            response.setSource(ResourceResponse::Source::MemoryCacheAfterValidation);
> 
> This code looks quite strange. Do we really call client->responseReceived
> before we know that revalidation succeeded? Or is validationInProgress a
> misnomer, and validation is actually complete and successful when this code
> runs?

This code runs when validation is just finishing. The whole thing is ugly but it is what it is. 

One of the reasons I'm adding test coverage is so that we can refactor memory cache to be better with more confidence in not breaking it.

> > Source/WebCore/loader/cache/CachedRawResource.cpp:184
> > -        c->responseReceived(this, m_response);
> > +        c->responseReceived(this, response);
> 
> This change is not mentioned in ChangeLog, what does it do?

Passes on the argument response object instead of the member since it can now be different. This was probably an oversight in the existing code since it didn't make any difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150807/b7341b4c/attachment-0001.html>


More information about the webkit-unassigned mailing list