Bug report: "start" and "end" don't seem to work together

[jamescridland]

https://op3.dev/api/1/redirect-logs?
start=2022-11-20T00:00:00.000Z&
end=2022-11-21T00:00:00.000Z&
format=json&
url=https://op3.dev/e,pg=9b024349-ccf0-5f69-a609-6b82873eab3c/podnews.net/audio/podnews*
&limit=10
&token=preview07ce

Using the above URL I get 10 results, with the last one timed at "time": "2022-11-20T22:21:49.933Z"

The API promises that "Results are returned in ascending order by time", so it looks as if this podcast might have 11 or 12 downloads in total for this day.

https://op3.dev/api/1/redirect-logs?
start=2022-11-20T00:00:00.000Z&
end=2022-11-21T00:00:00.000Z&
format=json&
url=https://op3.dev/e,pg=9b024349-ccf0-5f69-a609-6b82873eab3c/podnews.net/audio/podnews*
&limit=1000
&token=preview07ce

Using the above URL I get 1,000 results, with the last one timed at "time": "2022-11-20T09:07:19.705Z"

I am expecting all downloads from 2022-11-20T00:00:00.000Z until 2022-11-21T00:00:00.000Z to be returned in this call (up to the limit). This looks like a bug: and looks like I'm not supposed to be using start and end in the same call. Perhaps this might kick up an error.

[jamescridland]

Hmm, in fact...

https://op3.dev/api/1/redirect-logs?
startAfter=2022-11-20T00:00:00.000Z&
format=json&
url=https://op3.dev/e,pg=9b024349-ccf0-5f69-a609-6b82873eab3c/podnews.net/audio/podnews*
&limit=10
&token=preview07ce

...the above URL returns 10 records, with the last at "2022-11-20T22:21:49.933Z"

https://op3.dev/api/1/redirect-logs?
startAfter=2022-11-20T00:00:00.000Z&
format=json&
url=https://op3.dev/e,pg=9b024349-ccf0-5f69-a609-6b82873eab3c/podnews.net/audio/podnews*
&limit=1000
&token=preview07ce

...while the above URL returns a thousand, with the last at "2022-11-20T09:07:19.705Z".

I'm clearly doing something wrong, but I think I will admit defeat in my weekend coding.

[johnspurlock-skymethod]

I'm clearly doing something wrong,

Looking into this, the problem is on OP3's side - this will happen when using the special url wildcard syntax (which goes through a special codepath) catching multiple episode urls within the time period, and also using a limit.

I don't think it has anything to do with start and end, they seem to be respected: no results are returned outside of those bounds. The problem is that the query is looking for results first by "day", then in lexicographical order by url, then finally by time, since that is how the special index is sorted - so you'll see the "lowest" urls first (in your case, episodes from earlier in the year/last year).

Should be fixable, it will just result in reading more rows internally.

[johnspurlock-skymethod]

Ok, just pushed a fix cff06de to production, give it another shot and see if that looks better on your side.

[jamescridland]

That looks perfect, thank you.