Fix queued deployment visibility and lifecycle

[M-Hassan-Raza]

Closes #4072

Waiting application, Compose, and preview deployments appear immediately in history and keep the same attempt ID through execution. Queued logs switch to live output when execution starts, preview cards show the latest attempt, and waiting work preserves active-build visibility.

The web server and workers share one typed job contract. Atomic claims prevent duplicate execution; cloud dispatch is persisted with the attempt and recovered through Inngest. Queue cleanup cancels a snapshot of waiting IDs, preserving concurrent submissions and running builds. Webhooks return an error when enqueueing fails.

Rebased onto current canary. Migration 0198_queued_deployments follows upstream's 0197_logs_and_metrics; the upstream migration and snapshot are preserved.

Local validation:

• Full workspace build and all workspace typechecks passed.
• 131 test files passed: 1,301 tests passed, 10 skipped. The Docker-backed application execution file was excluded because the Docker daemon was unavailable.
• PostgreSQL fresh migration and upgrade from 198 to 199 migrations passed. Existing deployment data and upstream columns were preserved; migration reapplication and dispatch-row cascading were verified.
• Self-hosted runtime checks covered persisted enqueueing, waiting-job cancellation, worker claiming, failure recording, and queue draining.
• The deployment API and a real local Inngest server verified authentication, event delivery, duplicate rejection, queued cancellation, rejection of running cancellation, and cron recovery after an API transport failure. Runtime execution used unavailable local Docker/SSH targets to verify error transitions; successful container deployment was not verified.

Cloud rollout requires draining old runs, applying migration 0198, and upgrading the web server and deployment API together. Running cloud builds cannot be interrupted through queue cancellation. Upgrade and rollback requirements are documented in apps/api/README.md.

[M-Hassan-Raza]

Just noticed there was a conflict in the branch, have rebased now. Hope this PR gets a look, it looks like a common slop PR from the looks and size (size is mainly just the db snapshot) of it but I did test the code and refactored where I could see some slopification happeneing

[M-Hassan-Raza]

resolved another set of conflicts, might abandon this PR cuz it seems to be too big to be merged/reviewed (understandable even if most of the line are just snapshot file) or just not a priority atm

[imrja8]

@greptileai review this..

[greptile-apps]

Cleanup Cancels New Deployments

If a deployment is queued after Redis is flushed but before this database update runs, its BullMQ job survives while its deployment row is marked as cancelled. The worker can only transition rows from queued to running, so it rejects the cancelled row and aborts a valid deployment request.

[imrja8]

@M-Hassan-Raza are you active ready to fix few missing things?

[M-Hassan-Raza]

@M-Hassan-Raza are you active ready to fix few missing things?

Yeah whatever changes are required I can take a look

[imrja8]

Hey @M-Hassan-Raza

The deployment queue system has changed since your PR. BullMQ was replaced with an in memory queue for self hosted deployments and Inngest for cloud deployments. BullMQ is still used for scheduled backups, just not deployments.

If you revisit this, key things to check:

1. Self hosted deployment queue is now in apps/dokploy/server/queues/in-memory-queue.ts. There is no more Redis or BullMQ for deployments.

2. Cloud deployments go through apps/api/ via Inngest. Your deploymentId threading approach through apps/api/src/schema.ts and apps/api/src/utils.ts is still the right idea, but it needs to work with Inngest handlers now.

3. Race conditions to watch for include cancelled jobs getting claimed, aggregate status overwrites when deployments complete concurrently, and startup cleanup hiding active deployments.

4. Test both paths. Self hosted and cloud behave very differently now. IS_CLOUD uses a noop queue and HTTP forwarding.

For reference, my attempts at this:

#4774 was the first attempt and was closed due to scope issues.

#5422 had the self hosted side working with race condition fixes, but I am closing it because the cloud side was missing.

Let me know if you want to collaborate on this.

[imrja8]

Also check issue #4762