Summary

I'm not sure if this is a bug or feature request (probably the latter), but here is what I want to do vs what happens.

What I want

GIVEN events with revisions "m" through "n" exist for a certain aggregate (regardless of whatever other events exist),
WHEN I query for events using getEventsByRevision(aggregateId, m, n, callback),
THEN I expect to receive events with revisions "m" through "n" in the callback response.

What happens

GIVEN events with revisions "m" through "n" exist, BUT some events with revisions "0" through "m" (i.e. if any events between "0" and "m" do not exist),
WHEN (same as above),
THEN I receive the wrong events (sometimes no events)

When would this happen?

I have a use-case where we store lots of events for lots of aggregates, and we wanted a combination of speed and cheap(er) scalability (in terms of absolute event size). In other words, we didn't want an increasing number of events to slow down the querying of events too much.

Our solution was to write to 2 event stores simultaneously (using dynamo and redis), but only keep the most recent "N" events in the redis store for fast retrieval (once we've confirmed events were written to both stores). This means we have to remove old events (with old revisions) and want to continue being able to use the redis event store for querying in the same way.

How to fix

I made this work for our use-case a little while back, but then got busy and forgot to open a PR. I will link it shortly once I open it. This relaxes the constraints that all events (starting at revision 0) exist in the store, and retrieves the correct events by revision in either case (by using filter vs slice).

@adrai hope this makes sense. Let me know if you have questions about why or how, or changes you'd like to see.