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

[noyonalways]

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 apiGet sends params as ?input=<JSON> instead of named query params — all GET commands with parameters fail (400) #48 / GET (query) requests don't wrap input in {json: ...}, breaking every parameterized read against tRPC servers using the superjson transformer #46: those concern GET/read commands (apiGet query-param handling) and, per apiGet sends params as ?input=<JSON> instead of named query params — all GET commands with parameters fail (400) #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.

[noyonalways]

I'd like to work on fixing this one.

I've verified the mechanism in the generated source (src/generated/commands.ts — the application update action posts only the provided opts via apiPost("application.update", opts) with no read-merge), and I've got the repo set up locally with pnpm install / pnpm build / pnpm test all passing (18/18).

Since the command file is auto-generated from openapi.json via scripts/generate.ts (and CONTRIBUTING.md says not to edit the generated file by hand), I want to confirm the preferred direction before writing code:

1. Client-side read-merge — make generated update-style commands fetch current state (application.one) and merge provided flags before posting, so omitted fields are preserved. This mirrors the dashboard's edit behavior.
2. Server-side partial update — make application.update only touch keys present in the payload (fix lives in Dokploy proper, a different repo).
3. Generator-level change — modify scripts/generate.ts so it emits merge logic for all update commands, not just application.

Which direction would you prefer? If it helps, I can also reopen/re-check whether the GET/application.one issue (#48/#46) affects my ability to read state for the merge — I hit 400 on application one in this same 0.29.14 build.