Deployment worker does not reset status to error on failure — services stuck permanently in running state

Description

In apps/dokploy/server/queues/deployments-queue.ts, the BullMQ worker wraps all deployment logic in a try/catch, but the catch block only logs the error and does nothing to recover the service state:

async (job: Job<DeploymentJob>) => {
    try {
        if (job.data.applicationType === "application") {
            await updateApplicationStatus(job.data.applicationId, "running");
            // ... deploy or rebuild
        } else if (job.data.applicationType === "compose") {
            await updateCompose(job.data.composeId, { composeStatus: "running" });
            // ... deploy or rebuild
        }
    } catch (error) {
        console.log("Error", error);  // No status rollback
    }
}

The status is set to "running" at the start. If the deployment throws (network failure, Docker daemon crash, SSH timeout), the status is never reset.

The queue is also configured with removeOnComplete: true and removeOnFail: true, so there is no evidence left for debugging.

Impact

Any deployment that fails inside the worker leaves the service in a ghost "running" state. Users see a perpetual "deploying" indicator with no way to recover short of manually updating the database. Especially dangerous for automated webhook-triggered deployments where nobody is watching the UI.

Fix

Add status rollback in the catch block:

catch (error) {
    console.log("Error", error);
    if (job.data.applicationType === "application") {
        await updateApplicationStatus(job.data.applicationId, "error");
    } else if (job.data.applicationType === "compose") {
        await updateCompose(job.data.composeId, { composeStatus: "error" });
    } else if (job.data.applicationType === "application-preview") {
        await updatePreviewDeployment(job.data.previewDeploymentId, { previewStatus: "error" });
    }
}

Start in apps/dokploy/server/queues/deployments-queue.ts and trace the deployment worker's try/catch and the status helpers it calls. Verify that failed application, compose, and application-preview deployments end in their respective error status rather than remaining running.