<div dir="ltr">It looks like the train didn't roll forward today? I was going to swat out a new test that depends on 1.28.0-wmf.1 but 1.27.0-wmf.23 still looks to be running group2</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 9:01 AM, Chad Horohoe <span dir="ltr"><<a href="mailto:chorohoe@wikimedia.org" target="_blank">chorohoe@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Roan & Brad! We'll get back on track with wmf.1 deployments today :D<div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">-Chad</font></span><div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 11:08 PM, Roan Kattouw <span dir="ltr"><<a href="mailto:rkattouw@wikimedia.org" target="_blank">rkattouw@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>TLDR: the bug is fixed and the errors have stopped.<br><br></div>I started working around this train hold by backporting the entire Echo extension from wmf1 to wmf23, assuming that the bug would be in MW core and updating Echo wouldn't affect it. Right after I deployed that, these errors started being thrown by wmf1 too.<br><br></div>It turned out that one of the Echo changes I backported stores the integer -1 in redis under some circumstances. RedisBagOStuff treats integers specially, in order to make incr() work: it stores them as plain numbers instead of PHP-serialized data. But when retrieving this value, the code didn't recognize -1 as a plain number because it didn't consist solely of digits ('-' is not a digit), so it thought it was PHP-serialized data and passed it to unserialize(), which caused the error. Apparently no one had ever tried to store a negative integer in redis (!) until my Echo change exposed the bug.<br><br></div>Brad did all the hard work, diagnosing this and writing up a fix on Phabricator.  I turned that into a patch and deployed it about an hour ago. There haven't been any more errors since then.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, May 11, 2016 at 1:59 PM, Chad Horohoe <span dir="ltr"><<a href="mailto:chorohoe@wikimedia.org" target="_blank">chorohoe@wikimedia.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>When we deployed the first 1.28 release to the cluster yesterday, we got a new error[0] relating to</div><div>unserialization of redis data. It's pretty spammy already, so I'm paranoid about deploying wider until</div><div>we figure out why. Deploying some debugging work soon so we can figure out what's going on.</div><div><br></div><div>If you've got any information you think would help, please chime in on the bug.</div><div><br></div><div>-Chad</div><div><br></div><div>[0] <a href="https://phabricator.wikimedia.org/T134923" target="_blank">https://phabricator.wikimedia.org/T134923</a></div></div>
<br></div></div>_______________________________________________<br>
Engineering mailing list<br>
<a href="mailto:Engineering@lists.wikimedia.org" target="_blank">Engineering@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/engineering" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/engineering</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
Engineering mailing list<br>
<a href="mailto:Engineering@lists.wikimedia.org">Engineering@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/engineering" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/engineering</a><br>
<br></blockquote></div><br></div>