fix(schedule): await cloud schedule registration and validate jobs service response (#5139)

[fliptrigga13]

Summary

Resolves #5139: Dokploy Cloud application schedule runs manually but never executes automatically.

Root Cause

1. In apps/dokploy/server/api/routers/schedule.ts, the create mutation called the cloud schedule(...) utility without await:

   if (newSchedule?.enabled) {
       if (IS_CLOUD) {
           schedule({ ... }); // Unhandled detached promise
       }
   }

   Because schedule(...) was not awaited, the mutation returned newSchedule immediately. In serverless/cloud environments, detached background network promises may be terminated or suspended before completing the HTTP POST to ${process.env.JOBS_URL}/create-backup.
2. In apps/dokploy/server/utils/backup.ts, schedule(...), updateJob(...), and removeJob(...) performed HTTP requests via fetch but did not check result.ok. As a result, non-2xx HTTP responses (e.g. 400, 500) were silently returned as JSON without throwing, preventing callers from detecting registration failures.
3. Import path in backup.ts referenced @dokploy/server/index instead of the root package export @dokploy/server.

Fix

• Await Cloud Registration: Added await schedule({ ... }) in scheduleRouter.create matching the pattern used in updateJob and other routers.
• HTTP Response Validation: Added !result.ok check in schedule(...), updateJob(...), and removeJob(...) to throw a descriptive error containing HTTP status and response message on failure.
• Standardized Server Import: Fixed @dokploy/server package import in apps/dokploy/server/utils/backup.ts.

Test Plan

• Added unit tests in apps/dokploy/__test__/schedule/cloud-schedule-registration.test.ts (6/6 passed, 100% pass rate).
• Verified successful payload transmission and response handling.
• Verified error throwing on 4xx/5xx HTTP responses from the cloud jobs service.
• Verified cancelJobs batch removal in cloud mode.
• Ran Biome lint check across all modified files.

Closes #5139

Confidence Score: 3/5

The PR is not yet safe to merge because cloud failures can leave committed local records inconsistent with the jobs service.

Summary

• Standardizes the server package import.
• Adds response validation for create, update, and removal requests.
• Leaves local database mutations committed when newly surfaced remote failures occur, allowing orphaned or divergent schedule state.

_{Reviews (1) · Last reviewed commit: "fix(schedule): await cloud schedule regi..."}

[greptile-apps]

Registration failure leaves duplicates

When cloud registration fails, the enabled schedule has already been committed to the database, so this awaited call returns an error without removing that row. The dialog remains open and permits another submission, which inserts a schedule with a new ID. Repeated attempts can therefore create duplicate enabled schedules with no registered cloud job.

[greptile-apps]

Remote failures leave divergence

Callers commit local updates or deletions before these new non-2xx errors are thrown. For example, schedule deletion removes the database row before awaiting removeJob; if the jobs service rejects the request, the mutation fails while the remote job remains active, and the deleted record is unavailable for a normal retry. The same ordering around updateJob can leave locally committed settings that the remote service never accepted.

[narcisonunez]

Closing this PR as part of a bulk cleanup of automated/bot-generated submissions from this account. These PRs were opened in a tight, non-interactive burst (most within a ~2 hour window) with no accompanying human review, discussion, or testing evidence, so we're not able to verify the correctness or safety of the changes as submitted.

If any of the underlying issue(s) this PR references are still valid, please feel free to open a new PR with a human review process behind it, and we're happy to take another look.