-
Notifications
You must be signed in to change notification settings - Fork 20
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
lag is often innacurate #102
Comments
This issue is currently preventing us from using qstash in production. I can't count on the lag being accurate. |
Thanks for the report. This is prioritized and soon to be fixed. We will update here once the fix is on prod. |
I contact Upstash about this last week and got the response:
So this clearly is not a priority. @grantsingleton I'm now using pg_cron since it's extremely accurate for me, mentioned here #168 (comment) |
@mozeryansky this is fixed and deployed. Feel free to give it a shot and let us know. |
@grantsingleton The lag problem also fixed and deployed. Can you try again and let us know if you still see problems. |
I've been running a minute cron to requestcatcher for both qstash and pg_cron for the past 30mins, and I'm seeing identical responses of <1s. Thanks for the update on this. My use case is schedule, while this issue is about queues, so Grant's tests may be different. |
The lag is 0 even when messages are in the queue. It happens whether I am batching or enqueuing. It happens every time, so reproducible example would be to create a queue, publish or enqueue messages, and then read the lag.
When I first started using qstash it seemed to work. Sorry that I don't have a better description on how to reproduce, it just happens every time and with every queue now.
This queue has messages and is sending them, but the lag is 0.
The text was updated successfully, but these errors were encountered: