In an Appium run, what is the difference between deleting a session and letting the server reap it?
answer
- two ways to end, one teardown
- silence has a budget
- who decided, and who knows
- the client learns on the next command
basics
~10 sThe device-side teardown is identical. What differs is who decided and what the client knows: a reaped session is ended silently, so the client finds out only when its next command fails.
solid answer
~50 sA session ends one of two ways. Either the client sends `DELETE /session/:sessionId`, or the server ends it on its own after the session has sat idle longer than the budget `appium:newCommandTimeout` gives it in seconds. On the device the outcome is the same: the driver's agent session ends, the per-session ports come back, the slot frees, and device state the run changed survives in both cases. The difference is informational, and it is expensive. A delete is synchronous with the client's intent; a reap is not announced, so the client keeps going and discovers the session is gone only when its next command is answered against a session id that no longer exists. Everything the run still had to do — including teardown that needs the driver — never happens, and the failure lands on whichever command came next rather than on the silence that caused it.
go deeper
Know that a session can end two ways: your client deletes it, or the server ends it after the session has sat idle with no command for longer than its budget allows.
Explain that the device-side teardown is the same in both endings, and that the real difference is who decided and when the client finds out about it.
Be ready to read a run where the loss was a reap rather than a crash, and to say what the suite lost between its last command and the failure that got reported.
Own idle budgets as a fleet policy: long legitimate silences and quick device release pull in opposite directions, and someone has to make that call explicitly.
## Two ways an Appium session ends There are exactly two endings, and it is worth naming them separately because suites habitually treat them as one: 1. **The client deletes it.** `DELETE /session/:sessionId` is sent when your code quits the driver. The client asked, the server answered, and both sides agree the session is over. 2. **The server reaps it.** Every session carries an idle budget, expressed in seconds by `appium:newCommandTimeout`. If no command arrives within that window, the server ends the session on its own initiative. ## What is identical on the device Both endings run the same teardown, and this is the half people get wrong in the other direction — assuming a reap leaves a mess behind: - the driver's session with its device-side agent ends: on Android with the helper server it started, on Apple platforms with WebDriverAgent; - the host-side plumbing and per-session ports are released; - the server slot frees, so the device can take a new session; - device state the run changed — granted permissions, a simulated location, altered connectivity — survives, exactly as it does after a delete. A reaped session is not a leaked session. The device comes back. ## What differs | | Explicit delete | Idle reap | |---|---|---| | Who decided | the client | the server | | When the client learns | immediately, from the response | on its next command, which fails | | What was still pending | nothing; the run had finished | everything the run had left to do | | What the log shows | a delete right after the last command | a silent gap, then the server ending the session | ## Why the reap is the expensive ending for a run The cost is not the teardown. It is the distance between the cause and the symptom: - The failure appears at whatever command came *after* the silence, which is rarely the code responsible for it. - Teardown steps that need the driver cannot run, because there is no session left to run them against. - The failure message describes a command that would have worked perfectly well a moment earlier, which sends people looking at the app. - Re-running the case often passes, because the second run does not happen to pause in the same place, and the whole thing gets filed as flake. ## A birdwatching example The sightings suite runs in a pipeline job that has its own timeout. One night the job is killed while a long photo upload is in flight. The client process disappears without ever sending a delete, so from the server's point of view the session simply stops speaking. The session is held, doing nothing, until its idle budget runs out and the server ends it. The phone rejoins the pool minutes later than it should have, and nothing in the test report explains the gap — the report ends where the job was killed. That is the shape worth recognising: **a session with no delete is not an error, it is a delay**, and the reap is the mechanism that eventually cleans up after a client that never came back. ## Telling the two apart afterwards The server log distinguishes them cleanly, and elapsed time is the tell: 1. A **delete** appears immediately after the last command of a finished run. 2. A **reap** appears after a stretch with no incoming command at all, and the length of that stretch matches the session's idle budget. 3. A **crash** interrupts a command that was in flight — there is a command, and then a failure, with no silence in between. Those three read differently even at a glance, and mistaking the second for the third is what sends teams chasing device problems that were never there. ## Operating a suite where both happen - **Make the delete the normal ending.** Every finished run should show one, and a run without one is a signal about the runner or the client process rather than about the app. - **Treat the reap as a safety net, not a mechanism.** It exists so an abandoned session does not hold a device forever; it should not be how a suite routinely releases hardware. - **Size the idle budget against the longest legitimate silence your suite actually has**, not against a number copied from an example. - **Watch the gap between the last command and the ending.** On a shared fleet that gap is device time nobody is using, and it stays invisible until somebody looks for it. The underlying point is simple. Both endings free the device, so both are safe. Only one of them is *informative*, and a suite that leans on the uninformative ending will keep filing the same unexplained failure.
- Does a reaped Appium session still release the device?Yes. The server ends the driver session, so the agent session and the per-session ports come back exactly as they would after a delete. What is lost is everything the run still had to do, because the client was never told and keeps going until its next command fails.
- After the fact, how do you tell a reap from a crash?By the gap. A reap follows a stretch with no incoming command and ends the session on the server's own initiative; a crash interrupts a command in flight. The server log shows which happened, and the silence before a reap usually matches the session's idle budget.
saying these in an interview costs you the question
- Thinks a reaped session notifies the client that it was reaped
- Believes a reap leaves the device-side agent running
- Says a reaped session can be resumed from its session id
- Assumes the test's remaining steps still run after a reap
- Treats every mid-run session loss as a device crash