calling complete! on already completed task messes up stats

[ktsujister]

I'm not sure if this is as expected, but I found this behavior when I was trying stuff in REPL.

> (dq/put! q :test "test task")
> (def t (dq/take! q :test))
> (dq/complete! t)
true
> (get (dq/stats q) "test")
{:in-progress 0, :completed 1, :retried 0, :enqueued 1, :num-slabs 1, :num-active-slabs 1}
> (dq/complete! t)
true
> (get (dq/stats q) "test")
{:in-progress -1, :completed 2, :retried 0, :enqueued 1, :num-slabs 1, :num-active-slabs 1}

Is this expected behavior and the caller is responsible of keeping track of task status? If so, is there possibility of making status function public, so that we can check the status of the task?(currently it's private)

[ztellman]

Definitely not intentional, complete! should be idempotent.

[lkrubner]

I guess this is still an issue? I'm using the newest version of durable-queue, but I see the same issue:

  (Stats about from-tables-to-topics-queue:  {message {:num-slabs 1, :num-active-slabs 1, :enqueued 113245, :retried 0, :completed 113246, :in-progress -1}})

Also, I have 20 threads reading from this queue, and they then do an HTTP call, which is slow, so I am not surprised to see "20" as "in-process". But I am surprised to see a gap of 29 between enqueued and completed. I'm running this on an EC2 instance, and I know AWS has a reputation for poor I/O performance. Should I assume that the call to complete! is slow enough to explain the unexpected extra 9 between enqueued and completed?

Stats about the from-topics-to-persistence-queue:  {message {:num-slabs 1, :num-active-slabs 1, :enqueued 683, :retried 0, :completed 654, :in-progress 20}})