Summary
flash app delete <name> deletes the app record, prints an unqualified success message, and exits 0 — but the serverless endpoint it deployed is still there. The user is left with a live, billable endpoint they have been told is gone.
Reproduction
Deploy any Flash app, then delete it and ask a second question:
$ flash deploy
✓ deployed to production 2.5s
hello-flash https://jayf2t4qi40v9r.api.runpod.ai
$ flash app delete hello-flash
✓ deleted app hello-flash
$ runpodctl serverless list
[
{
"id": "jayf2t4qi40v9r",
"name": "hello-flash",
"workersMax": 1,
"idleTimeout": 60,
"flashboot": true,
...
}
]
runpodctl serverless delete jayf2t4qi40v9r then returns {"deleted": true} and the list returns [].
Expected
Either the endpoint is deleted along with the app, or the message says which resources were removed and which were not — for example deleted app hello-flash (endpoint jayf2t4qi40v9r not removed; delete it with ...).
As it stands there is no warning, no partial-success wording, and no non-zero exit. Nothing in the output distinguishes this from a complete teardown.
Why this one matters more than a cosmetic message
The orphaned endpoint scales to zero, so it costs nothing at rest — which is exactly why it can sit unnoticed indefinitely. It is not visible in flash app list afterwards, because the app record is genuinely gone; it is only visible through runpodctl or the console. A user following the documented teardown path has no reason to look there.
Anyone tearing down in a loop — CI, a test suite, a workshop, or a demo run repeatedly — accumulates these silently.
Environment
- Runpod Flash CLI v1.19.0
runpodctl 2.9.0-c094cac- Linux, Python 3.13
Suggested fix
Delete the endpoint as part of app delete, or fail loudly when the app record can be removed but its endpoint cannot. If leaving the endpoint is intentional, the success message should say so and name the command that removes it.
Related in spirit to #363 and #364: in all three cases the CLI reports what it attempted rather than what happened.
Summary
flash app delete <name>deletes the app record, prints an unqualified success message, and exits 0 — but the serverless endpoint it deployed is still there. The user is left with a live, billable endpoint they have been told is gone.Reproduction
Deploy any Flash app, then delete it and ask a second question:
runpodctl serverless delete jayf2t4qi40v9rthen returns{"deleted": true}and the list returns[].Expected
Either the endpoint is deleted along with the app, or the message says which resources were removed and which were not — for example
deleted app hello-flash (endpoint jayf2t4qi40v9r not removed; delete it with ...).As it stands there is no warning, no partial-success wording, and no non-zero exit. Nothing in the output distinguishes this from a complete teardown.
Why this one matters more than a cosmetic message
The orphaned endpoint scales to zero, so it costs nothing at rest — which is exactly why it can sit unnoticed indefinitely. It is not visible in
flash app listafterwards, because the app record is genuinely gone; it is only visible throughrunpodctlor the console. A user following the documented teardown path has no reason to look there.Anyone tearing down in a loop — CI, a test suite, a workshop, or a demo run repeatedly — accumulates these silently.
Environment
runpodctl2.9.0-c094cacSuggested fix
Delete the endpoint as part of
app delete, or fail loudly when the app record can be removed but its endpoint cannot. If leaving the endpoint is intentional, the success message should say so and name the command that removes it.Related in spirit to #363 and #364: in all three cases the CLI reports what it attempted rather than what happened.