[00:57] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/auditorclient-timeline/+merge/171942
[01:02] <wgrant> StevenK: Does that function correctly when given multiple objects, operations or actors?
[01:03] <StevenK> wgrant: Sprinkling an assert in the multiple test: reference = None
[01:03] <StevenK> actual    = "Object: ['lp-development:Person:243653', 'lp-development:Person:243654']; Operation: ('person-deleted', 'person-undeleted'), Actor: None"
[01:03] <wgrant> Right
[01:04] <StevenK> wgrant: Do you want that assert left in, or you wanted to see it cope?
[01:06] <wgrant> Confused
[01:06] <wgrant> Oh, by "wanted to see it cope" you meant "wanted to see it as a one off"?
[01:06] <wgrant> I don't much care.
[01:06] <StevenK> Yes, I did
[01:17] <StevenK> wgrant: Could I get a review, then?
[01:17] <StevenK> Or have you been defeated by connection limits?
[01:19] <wgrant> s/connection limits/questions/
[01:20] <wgrant> StevenK: We would ideally hook into auditorclient more directly, but this will do for now
[01:20] <wgrant> I think
[01:20] <wgrant> It might not actually work, though
[01:20] <wgrant> You should test
[01:21] <StevenK> Oh?
[01:21] <wgrant> The receive is also wrong
[01:21] <wgrant> The action should finish once auditorclient returns
[01:21] <wgrant> Not once everything is dereferenced
[01:21] <wgrant> Overlapping actions are generally a bad idea
[01:23] <StevenK> wgrant: http://pastebin.ubuntu.com/5806468/
[01:23] <wgrant> StevenK: Right
[01:24] <StevenK> wgrant: Any other concerns?
[01:25] <wgrant> I don't believe so.
[01:33] <StevenK> wgrant: That MP has updated.
[01:39] <wgrant> And is now approved.
[01:40] <StevenK> wgrant: Thanks
[04:11] <StevenK> wgrant: Do you want to review https://code.launchpad.net/~stevenk/launchpad/export-pu-auditor/+merge/171460 then?
[04:16] <wgrant> StevenK: What happens if I reject, accept, reject, and then accept an upload?
[04:21] <StevenK> wgrant: The last event's actor will be returned
[04:21] <wgrant> StevenK: Are you sure?
[04:22] <wgrant> There's a limit=1 on the single receive call
[04:22] <wgrant> But that doesn't quite work for the bulk one
[04:26] <StevenK> Let me write a test
[04:55] <StevenK> wgrant: Right
[04:57] <StevenK> wgrant: Calling reject, accept, reject with 3 different users results in the following: http://pastebin.ubuntu.com/5806804/
[05:07] <wgrant> StevenK: That shows that it happens to work at least sometimes
[05:07] <wgrant> I want to know whether it *should* work, or whether that's an accident.
[05:18] <StevenK> wgrant: Adding sleeps between the reject, accept and reject also returns the same returns.
[05:18] <StevenK> Which shows that it isn't just working due to the 2 events having the same timestamp
[05:19] <StevenK> s/same returns/same results/
[05:23] <wgrant> StevenK: That's not very strong evidence :)
[05:23] <wgrant> I'd really like to see eg. the request that goes to auditor, and the SQL behind it
[05:23] <wgrant> postgres will often return things in insert order initially on small tables
[05:23] <wgrant> Simply because of the likely physical layout
[05:23] <wgrant> I don't see how this works reliably, so I am inclined to believe it does not.
[05:24] <StevenK> wgrant: It's auditorfixture, so it's backed on sqlite
[05:24] <wgrant> s/postgres/sqlite/