log_event expects 'keys' to return a consistent order

[kareila]

This was fun to track down:

[Error: This event (uid=4, extra=new=V&old=D) was not found in logs at /dreamhack/home/8398-kareila/dw/cgi-bin/LJ/Event/SecurityAttributeChanged.pm line 47. @ newhack.dreamwidth.net]

This can happen whenever you delete or undelete an account. The error also gets printed to the browser in lieu of a normal page, which is very sad.

I checked my database, and the actual value for that event was (uid=4, extra=old=D&new=V). Hmm...

The set_statusvis user method calls log_event which uses a join on the return value of keys, which as all Perl lovers know USED TO return a consistently ordered array but no longer does so.

After logging the event, the page immediately tries to fire LJ::Event::SecurityAttributeChanged, which does this:

        my $extra = (1 == $action) ? 'new=D&old=V' : 'new=V&old=D';

        my $dbcr = LJ::get_cluster_reader($u);
        my $sth = $dbcr->prepare(
            "SELECT logtime, ip".
            " FROM userlog".
            " WHERE userid=? AND extra=?".
            " ORDER BY logtime DESC LIMIT 2");
        $sth->execute($u->{userid},$extra);

If the row isn't found, everyone dies, oh the embarrassment.

Other events that look up the value saved in this column use LJ::decode_url_string to decode the value in an order-agnostic way, but the easiest fix in this case is probably to search for either 'old=D&new=V' or 'new=V&old=D' (or vice versa).