Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More shenanigans with Conversation.get_events() #475

Open
Terrance opened this issue Jun 3, 2019 · 1 comment
Open

More shenanigans with Conversation.get_events() #475

Terrance opened this issue Jun 3, 2019 · 1 comment

Comments

@Terrance
Copy link
Contributor

Terrance commented Jun 3, 2019

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:

  1. 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?

  2. 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?

  3. 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.

  4. 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.

@tdryer
Copy link
Owner

tdryer commented Jun 25, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants