[Bug] Three tools give three different answers about one device: `session end` succeeds, `list-active` says RUNNING, `session create` says the device is in use

[informramiz]

Summary

For up to a minute after a successful session end, three tools disagree: session end returns success, list-active reports the same session RUNNING (in a row that also says ended active), and session create refuses the device as in use. It resolves itself within ~60s, but nothing tells the client that — so whether minutes are still accruing is unanswerable from the tool built to answer it.

Reproduction

Consecutive commands, no delay, one session:

$ kobiton session end
Session 8850652 ended.
EXIT=0

$ kobiton session list-active
Session 8850652, device 14c12053, status RUNNING, created 2026-08-05T17:39:43Z, ended active
EXIT=0

$ kobiton device adb-shell id
... status: NotFound, message: "Session not found or already ended" ...
EXIT=1

$ kobiton session end
Server error: {"error":{"message":"Cannot end this session","code":400,"status":"Bad Request"}} (400 Bad Request)
EXIT=1

$ kobiton -u 14c12053 session create
Server error: {"error":{"message":"The device is currently in use","code":400,"status":"Bad Request"}} (400 Bad Request)
EXIT=1

The strongest, timing-independent finding is the middle line: status RUNNING and ended active in the same row, about a session the previous command confirmed ended. That is a self-contradiction within a single response — no cooldown or eventual-consistency window explains a row that says both running and ended at once.

The last line — The device is currently in use about a device we released seconds earlier — was, in that first capture, consecutive commands with no delay, so a short post-end release window could account for it. A follow-up run re-polled at intervals to settle whether it clears on its own.

Timed re-poll (a second session, session end → poll at 0 / 30 / 60s)

A separate session (8866368, device ZY323T8MF9) was ended cleanly and then re-polled:

Since a clean session end	session list-active row for the session	session create retry on the same device
+0s	status RUNNING ... ended active (the contradiction above)	400 "The device is currently in use"
+33s	no longer listed	400 "The device is currently in use"
+65s	no longer listed	succeeds — device reacquired

So both symptoms are transient, not permanent: the contradictory list-active row clears within ~30s, and the device reacquires between 30s and 65s. This is an undocumented post-end cooldown of roughly 30–60s — eventual consistency, not a stuck device. What is missing is any way for a client to know that: session end returns success immediately, list-active briefly disagrees with itself, and session create reports a bare The device is currently in use with no retry-after.

Why this matters

Sessions are metered. A scripted loop that ends one session and opens the next on the same device fails, and the operator has no documented interval to back off by. list-active is the natural way to check whether you are still being billed, and it answers with a contradiction.

Asks

1. Make session list-active report a consistent state — status RUNNING ... ended active cannot both be true, even for the ~30s the row survives.
2. The post-end cooldown (measured at 30–60s above) is real but undocumented. Name it in session create's error: "device released Ns ago, retry in ~Ns" rather than a bare The device is currently in use, and/or have session end block until the device is actually free. Documenting the interval lets a scripted end-then-recreate loop back off correctly instead of guessing.

[TranKienCuong]

Thank you for the timed re-poll — it let us pin down both symptoms, and they turn out to be two separate, known mechanisms rather than a stuck device:

• The "device is currently in use" window is device cleanup. After a session ends, public cloud devices always go through an automatic cleanup before they can be booked again, which takes on the order of seconds to a few minutes depending on the device. Your 33s-fail / 65s-success timing is a normal cleanup cycle. The behaviour is expected; what's missing — as you said — is that nothing names it: the error doesn't say the device is cleaning or how long to back off.
• The contradictory list-active row is staleness, not two truths about the session. That view is served from a search index that can briefly lag the session record after a state change — for a short window it still shows the pre-end state. The end itself takes effect on the session record immediately, so a successfully ended session is not accruing during that window; the row you saw was a stale read, not continued billing.

Both legibility gaps are on us and we're looking at making the surfaces say what's actually happening — a consistent active-sessions view, and a rejection that names the wait.