- Imports store their cleanup data (names and paths, no credentials)
on the activity. When Coolify fails an import after a restart or as
stale, it queues a stop of the restore inside the database container
(only processes of that operation and their children, bottom-up so
the database server is not affected) and the normal cleanup.
- The cleanup runs once per import, and a stopped CoolifyTask does
not run again when the queue retries it.
- The stop message stays on the activity: RunRemoteProcess saves the
process id at start from the stored properties and keeps a stop
status at the end, and CoolifyTask::failed() keeps the message.
- Regenerate the OpenAPI spec (409 for database start, restart, and
import, plus earlier API changes that were missing).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Two parallel start requests both passed the in-progress check and got
200, because the start activity is created later by the queued action.
A per-database reservation (Cache::add, 600 s) is now taken before the
check, so the second request gets 409. The action releases it when it
creates its activity, skips, or fails. Restart, import, the deploy
API, MCP, and Livewire use the same reservation.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A Coolify restart now fails queued or running database imports, so
they no longer block all later imports with 409.
- An import without progress for the SSH command timeout plus 30
minutes (at least 2 hours) is stale and no longer blocks.
- The import sets its operation property when the activity is created,
so a worker cannot save the activity without it.
- Start and restart refuse a second operation while a start, restart,
or import is in progress, in the UI, the API (409), and actions.
- DatabaseStartJob runs only while its activity is still queued and
the newest one, and holds a lock per database during the commands.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hold a cache lock keyed by database UUID across the active-import
check and remote_process so two concurrent requests cannot both
queue a restore against the same database.
Andras BacsaiandClaude Opus 5.5