|
Whether or not a request is complete or complete-able is not based on server load. If you create a request for a range, it should be marked as complete if one of two things happens:
1. We already have events with no gaps that cover the entire time range of the request
2. We get a response from the server and it is empty, does not specify a next id, or the next id is an id we already have
As for the flags, GUILD_HISTORY_CATEGORY_UPDATE_FLAGs:
RESPONSE_RECEIVED refers to getting a response back from a client request (as opposed to the server pushing a new event)
NEW_INFO either means we received new events we didn't have before, or the category is now considered "up to date" which can happen if we requested latest info and got nothing new back but even knowing that is new info
REFRESHED refers to all the data needs to be reevaluated, right now only happening when permissions change
and GUILD_HISTORY_REQUEST_FLAG:
COMPLETE - We have gotten all events there are to get for the given time range and category
RESPONSE_PENDING - A request message from the client is in flight being processed by the server, waiting for a response
RESPONSE_PENDING_FROM_ADDON - Pairs with RESPONSE_PENDING, denoting that it was an add-on request. Not really used for anything atm tbh.
CHUNKS_DIRTY - Used internally to track updating and saving ranges
QUEUED - Request was made while on cooldown and allowed to queue, so it's in the queue waiting for cooldown to end so it can send to the server. Mutually exclusive with RESPONSE_PENDING
QUEUED_FROM_ADDON - Pairs with QUEUED, used internally to ensure requests from add-ons use add-on cooldown. Will be set if either the request was created by an add-on or if the call to RequestMoreEvents was fired from an add-on.
Note that DoesGuildHistoryHaveOutstandingRequest() specifically returns true if a request had an in flight message, i.e. RESPONSE_PENDING. Queued requests do not count as Outstanding. Requests that aren't complete do not count as Outstanding.
Also note that whenever we talk about gaps and ranges, the reason for the seemingly convoluted setup is because it facilitates being able to request events out of order. We use ranges and gaps to know where the wholes are in our requests so we don't miss events. In the old version of history, you could only request starting from now and going back in time. There was no way to get a specific range of time, which was what made it so annoying for add-ons like MM. Now we have a lot more control, but with that control comes more complication. We're working through those growing pains now. I appreciate your patience while we iron out the kinks. There are a lot of fixes coming thanks to the help of Siri and Sharlikran working with us over the last several weeks.
|