WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
200086
REGRESSION (
r247486
?): Flaky API Test TestWebKitAPI.WKWebView.LocalStorageProcessSuspends
https://bugs.webkit.org/show_bug.cgi?id=200086
Summary
REGRESSION (r247486?): Flaky API Test TestWebKitAPI.WKWebView.LocalStoragePro...
Aakash Jain
Reported
2019-07-24 10:05:20 PDT
TestWebKitAPI.WKWebView.LocalStorageProcessSuspends seems flaky. In
https://ews-build.webkit.org/#/builders/9/builds/4903
, the test Failed in run-api-tests step. However, in the immediately next retry step (re-run-api-tests), it passed. Same thing happened in
https://ews-build.webkit.org/#/builders/9/builds/4901
In
https://ews-build.webkit.org/#/builders/9/builds/4784
, it just failed consistently.
Attachments
Patch
(9.27 KB, patch)
2019-07-31 09:14 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ryan Haddad
Comment 1
2019-07-24 10:09:10 PDT
It can also be seen failing on a trunk bot here:
https://build.webkit.org/builders/Apple%20Mojave%20Debug%20WK2%20%28Tests%29/builds/3730/steps/run-api-tests/logs/stdio
Radar WebKit Bug Importer
Comment 2
2019-07-24 10:09:26 PDT
<
rdar://problem/53501721
>
Ryan Haddad
Comment 3
2019-07-29 14:14:38 PDT
This is indeed quite flaky. The bots are often red because of this failure. TestWebKitAPI.WKWebView.LocalStorageProcessSuspends /Volumes/Data/slave/ios-simulator-12-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStoragePersistence.mm:156 Expected equality of these values: @"value" Which is: "value" result Which is: "newValue"
Aakash Jain
Comment 4
2019-07-29 16:01:21 PDT
This test is creating issue in EWS infrastrucutre. It is extremely flaky and various times flakes in a manner that misleads EWS into blaming the patch being tested (this test failed consistently twice with the patch, and pass without the patch). e.g.:
https://ews-build.webkit.org/#/builders/9/builds/5177
https://ews-build.webkit.org/#/builders/9/builds/5145
https://ews-build.webkit.org/#/builders/9/builds/5140
https://ews-build.webkit.org/#/builders/9/builds/5109
Sihui Liu
Comment 5
2019-07-29 16:51:28 PDT
(In reply to Aakash Jain from
comment #4
)
> This test is creating issue in EWS infrastrucutre. It is extremely flaky and > various times flakes in a manner that misleads EWS into blaming the patch > being tested (this test failed consistently twice with the patch, and pass > without the patch). > > e.g.: >
https://ews-build.webkit.org/#/builders/9/builds/5177
>
https://ews-build.webkit.org/#/builders/9/builds/5145
>
https://ews-build.webkit.org/#/builders/9/builds/5140
>
https://ews-build.webkit.org/#/builders/9/builds/5109
Do you mean this API test always passes without those patches being tested but fails with them? It sounds like some states are kept between test runs.. Does this happen since last week? If this starts to happen recently, it may help narrow down the blamed changes.
Ryan Haddad
Comment 6
2019-07-29 16:56:39 PDT
FWIW this isn't specific to iOS. Based on history, this may have started after: Speed up StorageManager::getValues()
https://trac.webkit.org/changeset/247486/webkit
Chris Dumez
Comment 7
2019-07-29 17:03:15 PDT
(In reply to Ryan Haddad from
comment #6
)
> FWIW this isn't specific to iOS. > > Based on history, this may have started after: > > Speed up StorageManager::getValues() >
https://trac.webkit.org/changeset/247486/webkit
Ok, so probably making it a WorkQueueMessageReceiver again.
Aakash Jain
Comment 8
2019-07-29 17:05:43 PDT
> Do you mean this API test always passes without those patches being tested > but fails with them?
Not always. It flakes in various different manners. This particular manner is particularly bad for EWS (as it incorrectly blames a patch). In following examples, the test is clearly flaky; it failed in first run (run-api-tests step), but in immediate retry step (in re-run-api-tests) this test passed:
https://ews-build.webkit.org/#/builders/9/builds/5199
https://ews-build.webkit.org/#/builders/9/builds/5183
https://ews-build.webkit.org/#/builders/9/builds/5179
https://ews-build.webkit.org/#/builders/9/builds/5176
https://ews-build.webkit.org/#/builders/9/builds/5170
https://ews-build.webkit.org/#/builders/9/builds/5163
https://ews-build.webkit.org/#/builders/9/builds/5157
https://ews-build.webkit.org/#/builders/9/builds/5151
https://ews-build.webkit.org/#/builders/9/builds/5123
https://ews-build.webkit.org/#/builders/9/builds/5120
https://ews-build.webkit.org/#/builders/9/builds/5119
https://ews-build.webkit.org/#/builders/9/builds/5114
https://ews-build.webkit.org/#/builders/9/builds/5103
https://ews-build.webkit.org/#/builders/9/builds/5102
> > Does this happen since last week? If this starts to happen recently, it may > help narrow down the blamed changes.
Seems to be happening atleast since July 16:
https://ews-build.webkit.org/#/builders/9/builds/4550
https://ews-build.webkit.org/#/builders/9/builds/4547
https://ews-build.webkit.org/#/builders/9/builds/4545
Chris Dumez
Comment 9
2019-07-31 09:14:22 PDT
Created
attachment 375227
[details]
Patch
WebKit Commit Bot
Comment 10
2019-07-31 10:37:57 PDT
Comment on
attachment 375227
[details]
Patch Clearing flags on attachment: 375227 Committed
r248047
: <
https://trac.webkit.org/changeset/248047
>
WebKit Commit Bot
Comment 11
2019-07-31 10:37:59 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug