I see this frame if I create and trash a collection in a different tab:
{
"event_at": "2017-07-12T13:54:31.604427Z",
"event_type": "update",
"id": 44991169,
"msgID": 29,
"object_kind": "arvados#collection",
"object_owner_uuid": "4xphq-j7d0g-j7vfmt308hc1a9l",
"object_uuid": "4xphq-4zz18-q1r66no80m6owgo",
"properties": {
"new_attributes": {
"name": "New collection (2017-07-12T13:53:48.867Z)",
"owner_uuid": "4xphq-j7d0g-j7vfmt308hc1a9l",
"portable_data_hash": "d41d8cd98f00b204e9800998ecf8427e+0"
},
"old_attributes": {
"name": "New collection (2017-07-12T13:53:48.867Z)",
"owner_uuid": "4xphq-j7d0g-j7vfmt308hc1a9l",
"portable_data_hash": "d41d8cd98f00b204e9800998ecf8427e+0"
}
},
"uuid": "4xphq-57u5n-r8znuqy2qusqwu2"
}
I think the reliability issue is a permission-checking bug.
- Collection gets trashed
- Websocket server sees the event and checks permission
- If permission is already cached because this client saw the "create" event (or some other event with the same object_uuid) then the event is sent
- If permission is not cached, the permission check fails because "get collection" returns 404 for a collection that has just been trashed.
For the collection-trashing case, the solution is to use the include_trash parameter when checking permission. For real "delete" events, that won't help. Checking permissions on object_owner_uuid instead of object_uuid will catch most cases. Clients still won't see "delete" events for objects in projects they can't see (i.e., where they have permission only by virtue of a permission link), though.