Ensure all server events and their operations are handled

[borisyankov]

We are handling almost all server events and the majority of their operations.
The ones not being handled have not been a priority to implement until now.

With the approaching implementation of Queue 2.0 we will stop refreshing our internal state frequently and it will be essential for the state consistency to add handling for the remaining ones.

---

[We've edited this list over time to try to keep it up to date. -- Greg]

For documentation of each of these, see: https://zulip.com/api/get-events

• alert_words
• presence
• reaction
  • add
  • remove
• realm
  • update / update_dict
    • with property allow_edit_history, treat similarly to a restart event (in particular, a restart event where the server version changed, which could mean any number of subtle changes in server behavior), and do a re-fetch of server data soon after. Because Message objects' edit_history property will be stale. messages reducer: Sketch a plan for keeping Message.edit_history current #5422 (comment)
• realm_bot
  • add
  • remove, delete
  • update
• realm_emoji - ??? - nope
• realm_filters - ??? - nope
• realm_domains - ??? - add, change, remove
• realm_user
  • add
  • [?] remove / EVENT_USER_REMOVE
  • update / EVENT_USER_UPDATE - includes a user changing email, name, or avatar - Doesn’t update my own avatar #3397, Handle user update events #3403, see also Make sure the app doesn't break with the new delivery_email field #3196 (comment)
  • update / EVENT_USER_UPDATE as to your own email, in state.accounts (but fully handling that case will also require handling when it happens while we aren't online and don't have an event queue -- should probably become a separate issue)
• submessage - Add basic support for submessages/widgets #3220
• subscription
• peer_add
• peer_remove
• stream / EventTypes.stream
  • occupy
• typing
• update_display_settings deprecated -> user_settings (Execute the user_settings object transition #4933)
• update_message_flags
  • marking as unread Respect unread message status from "mark as unread" in webapp #5361
  • [?] other cases
• user_group -
• user_settings
• user_status
• update_message - full support in all reducers that care about messages
  • (see git grep -L EVENT_UPDATE_MESSAGE: -- $(git grep -l EVENT_NEW_M src/*/*Reducer*))
  • unread - unreadModel: respond to message topic/stream edits #4840
  • topics (See Update state.narrows on topic/stream edits #2688)
  • streams (See Support moving messages between streams #3957)
  • narrows
  • message (in particular, record stream moves)
• delete_message - full support in all reducers that care about messages
  • topics
  • flags
• restart - Refetch server data from scratch after server upgrade #4793

Since #5310, see also the event types we explicitly ignore at the end of eventToAction. (Many of those are for product features we simply don't support, though, and those are out of scope for this issue -- we'll handle them as part of adding those features.)

[gnprice]

Thanks @borisyankov for writing this up!

I just added a few items; if I see more in this category I'll add them too.

[chrisbobbe]

If "Queue 2.0" is "long-lived event queues," linking #3916.

Also, just added stream_occupy to deduplicate #2604.

[gnprice]

If "Queue 2.0" is "long-lived event queues,"

Yep, that's right. Thanks!

[chrisbobbe]

Quoting Tim from zulip/zulip#10044 (comment):

For events, from a mobile team perspective, one useful existing resource is the schema definitions in test_events.py. E.g.

    def test_update_message_flags(self) -> None:                                                     
        # Test message flag update events                                                            
        schema_checker = self.check_events_dict([                                                    
            ('all', check_bool),                                                                     
            ('type', equals('update_message_flags')),                                                
            ('flag', check_string),                                                                  
            ('messages', check_list(check_int)),                                                     
            ('operation', equals("add")),                                                            
        ])                                                                                           
                                                                                                     
        message = self.send_personal_message(                                                        
            self.example_email("cordelia"),                                                          
            self.example_email("hamlet"),                                                            
            "hello",                                                                                 
        )                                                                                            
        user_profile = self.example_user('hamlet')                                                   
        events = self.do_test(                                                                       
            lambda: do_update_message_flags(user_profile, 'add', 'starred', [message]),              
            state_change_expected=False,                                                             
        )                                                                                            
        error = schema_checker('events[0]', events[0])                                               
        self.assert_on_error(error)                                                                  
        schema_checker = self.check_events_dict([                                                    
            ('all', check_bool),                                                                     
            ('type', equals('update_message_flags')),                                                
            ('flag', check_string),                                                                  
            ('messages', check_list(check_int)),                                                     
            ('operation', equals("remove")),                                                         
        ])                                                                                           

I think if we were to provide schema documentation for the events, I'd want it to be something that shares code with these tests, so it doesn't get stale, but I think a reasonable v1 for the mobile folks would be to ensure everyone's familiar with how to read the test_events tests, since they generally have complete coverage for the corner cases around a given event.

(And display_recipient is quite rare in being a concept that has variable type; almost all events are very consistently structured)

[gnprice]

An update to this issue's description: happily, this part of the Zulip API is now documented!
https://zulip.com/api/get-events

So the reverse-engineering discussed above should no longer be necessary.