Repository navigation
GET (query) requests don't wrap input in {json: ...}, breaking every parameterized read against tRPC servers using the superjson transformer #46
Description
Bug
apiPost in dist/client.js correctly wraps mutation payloads as { json: data } before sending, matching tRPC's superjson transformer convention:
export async function apiPost(endpoint, data) {
const client = createClient();
const response = await client.post(`/trpc/${endpoint}`, data ? { json: data } : undefined);
...
}apiGet does not — it sends the raw params object as the query string, unwrapped:
export async function apiGet(endpoint, params) {
const client = createClient();
const query = params
? `?input=${encodeURIComponent(JSON.stringify(params))}`
: "";
...
}Against a Dokploy server using the superjson transformer, any query procedure that requires input parameters fails with a 400:
{
"error": {
"json": {
"message": "[\n {\n \"expected\": \"object\",\n \"code\": \"invalid_type\",\n \"path\": [],\n \"message\": \"Invalid input: expected object, received undefined\"\n }\n]",
"code": -32600,
"data": { "code": "BAD_REQUEST", "httpStatus": 400, "path": "application.one", ... }
}
}
}Repro
dokploy application one --applicationId <id>
# Request failed with status code 400No-argument queries (e.g. project all) work fine, since an empty/undefined input happens to satisfy those procedures' schemas either way — which is why this doesn't show up immediately.
Expected
apiGet should wrap params the same way apiPost wraps data:
const query = params
? `?input=${encodeURIComponent(JSON.stringify({ json: params }))}`
: "";Environment
@dokploy/cli0.29.4 (reportsdokploy --version→ 0.3.0)- Dokploy server v0.29.11
- Affects any query command that takes parameters:
application one,deployment all,mounts list-by-service-id, log reads, etc.
Activity
ambymon commentedon Jul 28, 2026
Confirming this on a live Dokploy v0.29.13 panel with CLI 0.29.4 — the diagnosis holds exactly:
It hits every parameterized query I tried (
application one,deployment all,project one,environment one).project allis the only survivor, because it takes no input at all.Note for whoever picks this up: #45 already fixes the symptom, but by moving the client to the REST routes rather than wrapping the input. If a minimal tRPC-side fix is preferred instead, the unwrap has to stay — the tRPC route returns
{"result":{"data":{...}}}while REST returns the bare object:So wrapping the request without keeping
?.result?.data?.jsonwould break the same reads a second time, just one layer further in.refactor(cli): migrate to Bun and target the REST API
thomasorgeval commentedon Aug 28, 2026
Confirmed on @dokploy/cli 0.30.2.
Additional reproduction:
For docker.getServerHealth, sending the same values to the tRPC endpoint with input encoded as {"json":{"serverId":"REDACTED","sinceHours":1}} returns 200. This confirms that the healthcheck failure in 0.30.2 is another instance of the generic apiGet wrapping issue described here.
cavalinho-xdd commentedon Oct 9, 2026
Still reproducible with @dokploy/cli 0.30.7 (latest on npm) against a Dokploy v0.30.8 server:
application one,project oneanddeployment allall returnRequest failed with status code 400, while parameterless commands likeproject allwork.Wrapping the GET input as
?input={"json":{...}}fixes it. The approach in #52 works for me. Could #52 be merged and released? Until then, every read command that takes an ID is unusable.