This would be correct, that's working as intended. Otherwise the cache could just be bypassed by setting different timestamps constantly? This is more of an issue for other selections that utilize the 'to' timestamp.
Was this cache for the log API introduced with the latest change? I have scripts that appeared to be functioning normally before the API rework but now don't seem to be behaving properly and wondering if it's related to this when the only thing I've changed is putting in the Full Access API Key. I haven't had the chance to look into it further though to confirm.
I should note that my scripts heavily utilize timestamps to loop through the log API.
If you're going to introduce a cache for the log API like this then can the limit be increased on how many results we can retrieve with one call or something?
I might be misunderstanding the purpose of the cache but is it not to reduce server load by not sending a request to the servers when a duplicate call is made? In this case, a call that should return different information is being cached.
This does appear to of been a bug introduced in the latest API version, up until this change I could request logs using the to field and get unique results up to the API requets limit per minute. Now it will only return the cached result for some length of time.
yeah this really annoying I've been banging my head to the desk for the last week because my script to calculate revives isn't working (infinite loop) because i use the last timestamp as the new timestamp in the new query and the results doesn't seem to stop because i get the same result from the last search so it keeps going forever