Description
Related Objects
Event Timeline
Change 286119 had a related patch set uploaded (by AndyRussG):
Ensure consistent ordering of choiceData for RL module hashes
I was able to verify that this is due to ordering. I sent repeated requests for https://en.wikipedia.org/w/load.php?modules=ext.centralNotice.choiceData to appservers.svc.eqiad.wmnet until I got two different responses. I stripped the JavaScript wrapping to leave just the JSON, and expanded !0 and !1 to obtain valid JSON. I then parsed the JSON and reserialized it with the pretty-printing option enabled, so I could get a meaningful diff.
The only differences the diff shows are in the ordering of the keys in the mixin objects. The perflogbot log shows this module flapping between just two distinct hash values, and I found two distinct responses, so that means there aren't any other flapping issues, at least with the configuration we have on enwiki right now. It is possible that there are other lists that are inconsistently ordered, but there are <2 items in those lists right now, so we still want to audit that and ensure everything has a consistent order.
Change 286126 had a related patch set uploaded (by AndyRussG):
Ensure consistent ordering of choiceData for RL module hashes
Change 286119 abandoned by AndyRussG:
Ensure consistent ordering of choiceData for RL module hashes
Reason:
Superseded by I13ae9c696
Change 286126 merged by jenkins-bot:
Ensure consistent ordering of choiceData for RL module hashes
Change 286183 had a related patch set uploaded (by Jforrester):
Ensure consistent ordering of choiceData for RL module hashes
Change 286183 merged by jenkins-bot:
Ensure consistent ordering of choiceData for RL module hashes
Mentioned in SAL [2016-04-29T19:56:14Z] <catrope@tin> Synchronized php-1.27.0-wmf.22/extensions/CentralNotice/: T133971 (duration: 00m 41s)