You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm aiming to write a get-history method that takes an optional start point and produces a list of messages, either the most recent or before the given message (which may not be in the conversation cache, e.g. stored from a previous session, meaning I need to iterate over the event history to find them).
In theory Conversation.get_events() should cover it, but it isn't behaving quite how I'd expect:
If there are no cached events in conv.events, get_events() with no args will just returns an empty list of events without trying to fetch any. get_events(event_id), assuming you manage to obtain an initial event, will fail as it references self._events[0].
Is this a case that actually happens, or are we guaranteed to always have at least one event for any conversation? I have some empty conversations with no events, but if there's no initial event then can I assume there are none to be obtained either?
If the requested event is beyond the cache, we fetch one page of events (presumably following the earliest cached, given the internal timestamp) and return that, which may or may not include events directly following the desired start position.
If the API doesn't let us fetch messages by ID, we should probably just do nothing if we don't know about a given ID?
Repeatedly calling conv.get_events(conv.events[0].id_) works up until the last event, at which point I should get an empty list but instead seem to get an end batch of events again.
A couple of conversations I'm retrieving have used OTR -- the event history consists of a single on-record message in the past, and a batch of current off-record messages. There should be more events before the oldest off-record message, but attempting to retrieve more presumably uses the earlier on-record timestamp, and the above causes the last batch to be returned again. Probably invalid as I was comparing to the web client which had messages past the 24 hour limit cached.
Is this a case that actually happens, or are we guaranteed to always have at least one event for any conversation? I have some empty conversations with no events, but if there's no initial event then can I assume there are none to be obtained either?
No, that sounds like an oversight. build_user_conversation_list tries to initially load one event for each conversation, so it's a rare case.
If the API doesn't let us fetch messages by ID, we should probably just do nothing if we don't know about a given ID?
I'm not sure what the best way to handle that it is. The mismatch between get_events interface and the underlying API is not ideal.
I'm aiming to write a get-history method that takes an optional start point and produces a list of messages, either the most recent or before the given message (which may not be in the conversation cache, e.g. stored from a previous session, meaning I need to iterate over the event history to find them).
In theory
Conversation.get_events()
should cover it, but it isn't behaving quite how I'd expect:If there are no cached events in
conv.events
,get_events()
with no args will just returns an empty list of events without trying to fetch any.get_events(event_id)
, assuming you manage to obtain an initial event, will fail as it referencesself._events[0]
.Is this a case that actually happens, or are we guaranteed to always have at least one event for any conversation? I have some empty conversations with no events, but if there's no initial event then can I assume there are none to be obtained either?
If the requested event is beyond the cache, we fetch one page of events (presumably following the earliest cached, given the internal timestamp) and return that, which may or may not include events directly following the desired start position.
If the API doesn't let us fetch messages by ID, we should probably just do nothing if we don't know about a given ID?
Repeatedly calling
conv.get_events(conv.events[0].id_)
works up until the last event, at which point I should get an empty list but instead seem to get an end batch of events again.A couple of conversations I'm retrieving have used OTR -- the event history consists of a single on-record message in the past, and a batch of current off-record messages.
There should be more events before the oldest off-record message, but attempting to retrieve more presumably uses the earlier on-record timestamp, and the above causes the last batch to be returned again.Probably invalid as I was comparing to the web client which had messages past the 24 hour limit cached.May be related to #462, #467.
The text was updated successfully, but these errors were encountered: