Bug: `dokploy application update` nullifies omitted settings (sourceType, buildType, triggerType, autoDeploy, ...)

src/generated/commands.ts の836–960行付近を読み、次に application.one と application.update がどのように使われているかを調べてください。部分更新のセマンティクスをクライアントとサーバーのどちらで適用すべきかを判断してください。1つの指定フィールドを更新したときに、sourceType、buildType、triggerType、autoDeploy などの省略された設定が保持されれば完了です。

Bug: dokploy application update nullifies omitted settings (sourceType, buildType, triggerType, autoDeploy, ...)

Summary

dokploy application update sends only the flags provided on the command line as the full request body. Every setting not explicitly passed is omitted from the payload, and the server's application.update overwrites those omitted fields (observed: sourceType, buildType, triggerType, autoDeploy reset to null/None). Changing a single field via the CLI silently wipes other important application settings.

Environment

• dokploy --version → 0.29.14
• CLI package: @dokploy/cli 0.29.14
• Server: self-hosted Dokploy (redacted host)

Repro (user-observed)

1. Create an application with a real source (github), a buildType (e.g. nixpacks), and autoDeploy enabled.
2. Run a partial update of one field:

   dokploy application update --applicationId <id> --name "Renamed"
   

3. Open the application in the dashboard.

Expected: only name changes; sourceType, buildType, triggerType, autoDeploy remain.

Actual: sourceType, buildType, triggerType, autoDeploy are reset to None/empty.

Root cause (verified in src/generated/commands.ts, lines ~836–960)

The generated application update action collects only the flags the user provided into opts and posts them directly:

const data = await apiPost("application.update", opts);

opts is never merged with the current application state read from application.one. Any field the user does not pass is therefore absent from the request body. The server's application.update tRPC procedure treats the submitted body as the desired full state and overwrites omitted fields with null/undefined, rather than leaving them unchanged.

The CLI treats update as "send what I gave you" (partial intent), while the server treats the body as authoritative/full state — a partial-update contract mismatch. The dashboard edit form does a read-then-patch merge; the CLI does not.

Additional environment note

The companion read command used to inspect before updating is currently broken too: dokploy application one --applicationId <id> fails with 400 (related to issue #48/#46 — apiGet query-param handling). Reading via a correctly-encoded API call (/api/application.one?applicationId=<id> with x-api-key) returns the full object and confirms the at-risk fields are populated (e.g. sourceType: "github", buildType: "nixpacks", triggerType: "push", autoDeploy: true).

Suggested directions (maintainers to decide)

1. Client-side fix: in the application update action, first fetch the current app (application.one), merge the provided flags over the returned state, and send the complete object — matching the dashboard's read-then-patch behavior.
2. Server-side fix: make application.update a true partial merge (only update keys present in the payload), which would also make the CLI's current behavior correct.

Notes

• Distinct from issues #48 / #46: those concern GET/read commands (apiGet query-param handling) and, per #48, explicitly do not affect update (a POST).
• I did not run a destructive partial update against a live production application to reproduce, to avoid wiping real settings; the mechanism is confirmed from the generated source and the values at risk were confirmed present via the working read endpoint.