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

'before' options returns too many things #76

Open
janssen-io opened this issue Jan 22, 2018 · 0 comments
Open

'before' options returns too many things #76

janssen-io opened this issue Jan 22, 2018 · 0 comments

Comments

@janssen-io
Copy link

janssen-io commented Jan 22, 2018

When requesting for example the newest comments in a subreddit, adding the 'before' option shows all comments. The expected result would be all comments newer than the comment specified (fullname of the comment passed via 'before:').

Example:

comments = session.subreddit('scotch').comments(before: 't1_dt288wj') # substitute with more recent fullname
enum = comments.stream

100.times do
  puts enum.next.name
end
# observe that at some point we get the comment with the given fullname and
# afterwards all the older comments ordered by descending time.
# likewise for enum = comments.each

Version: 0.9.0.pre.3

Analysis

My guess is that it comes from #fetch_prev_listing in PaginatedListing. If the returned listing is empty, it will set @before to nil. Is this intended behaviour? I would expect one of three things:

  1. Raise a StopIteration
  2. Return nil
  3. Block and poll frequently until a new listing item (comment in this case) is available.

Raising StopIteration would have my preference, but that might make it harder to restart the listing. Blocking would be difficult if you want to combine different streams. For example, if you would want to iterate over both comments and submissions at the same time. (addition:) Instead of blocking, we could also use the concurrent-ruby gem to do the polling on a separate thread. Anytime when new data is available we can send a message to the obserber/block.

If this is intended behaviour, how would I approach this in an application where I only want to receive newer items?

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

No branches or pull requests

1 participant