Schedules, volume backups and ports are broken on canary: cannot pass more than 100 arguments to a function

[dmtrTm]

To Reproduce

On current canary (any commit that includes migration 0175_fantastic_peter_quill.sql):

1. Create an Application
2. Add a Schedule to it (Advanced → Schedules), or a Volume Backup, or open an existing published Port
3. Trigger any of:
   • the schedule running on its cron, or "Run manually"
   • the volume backup running on its cron, or "Run manually"
   • viewing / updating / deleting a port

Each fails. The UI shows a generic message ("Port not found", or the run simply never happens);
the real cause is not surfaced anywhere.

To see the real error, call the finders directly against the database, bypassing the routers:

await finPortById() → PostgresError 54023
await findScheduleById() → PostgresError 54023
await findVolumeBackupById() → PostgresError 54023

cannot pass more than 100 arguments to a function

Current vs. Expected behavior

Current behaviour: every by-id read of a port, schedule or volume backup fails with Postgres error
54023 (cannot pass more than 100 arguments to a function). Scheduled jobs therefore never execute:
apps/schedules/src/utils.ts:108 and :114 call findScheduleById / findVolumeBackupById before running
anything, so both cron paths die at the first query. Volume backups silently stop being taken.

The failure is invisible from the API and from the logs, because the routers wrap the cause in a
generic TRPCError without logging it — e.g. apps/dokploy/server/api/routers/port.ts:52-58 rethrows
BAD_REQUEST "Port not found" with the real error attached as cause, which tRPC does not send to
the client.

Expected behaviour: schedules run, volume backups run, ports can be read and edited.

Provide environment information

Operating System:
  OS: macOS 26.5.2 (local dev instance, `pnpm dokploy:dev`)
  Arch: arm64

Dokploy version: canary (v0.29.13 + migration 0175); not present in any released tag
Postgres: 16.14
Docker: 29.6.1
VPS Provider: n/a — reproduced locally; production on v0.29.13 is not affected
What applications/services are you trying to deploy?
  Any application using Schedules, Volume Backups or published Ports

Which area(s) are affected? (Select all that apply)

Application, Databases, Docker

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Root cause

Drizzle compiles a nested relation into a single json_build_array(...) call containing every column of
the related table plus one blob per further nesting level. Postgres caps that at the hard-compiled
FUNC_MAX_ARGS = 100.

0175_fantastic_peter_quill.sql (network management) added networkIds and detachDokployNetwork,
taking application from 99 to 101 columns. Queries that hydrate application → environment → project
went from 99 + 1 = 100 arguments — exactly on the limit — to 102, and now fail.

Four call sites have that shape. Measured on a canary instance:

finder	file	status
findRollbackById	packages/server/src/services/rollbacks.ts:106	54023 — fixed in #4924
finPortById	packages/server/src/services/port.ts:28	54023
findScheduleById	packages/server/src/services/schedule.ts:79	54023
findVolumeBackupById	packages/server/src/services/volume-backups.ts:11	54023

application (101 columns) is the only table over the limit — the next largest is compose at 46 — so
these four are the complete set.

Everything else already narrows its nested application selection and is unaffected: findDeploymentById,
centralizedDeploymentsWith, findPreviewDeploymentById, and the domain / mount / server / environment
finders. project.all, project.one, application.one, deployment.all, domain.byApplicationId,
schedule.list, volumeBackups.list and previewDeployment.all all still return 200.

This is the third time

• Preview deployments broken on v0.29.0: cannot pass more than 100 arguments to a function #4256 / fix: preview deployments broken on v0.29.0 — postgres 100-arg limit #4257 — same failure in findPreviewDeploymentById, fixed 2026-04-19 by narrowing the nested
  selection with columns:.

• feat: add pre-deploy and post-deploy command hooks for applications #4240 called the ceiling out in advance:

  the application table already has 99 columns on canary, and Postgres caps json_build_array() at
  100 arguments … any additional column from any PR will re-trip this

  That PR deliberately packed two settings into one column to stay at exactly 100. Migration 0175 then
  added two columns.

Suggested fix

Same form as #4257 — narrow each nested application to the columns its consumers actually read:

• finPortById — consumers read only port.application.applicationId
  (apps/dokploy/server/api/routers/port.ts:48,66,93)
• findScheduleById — consumers read application.appName and application.serverId
  (packages/server/src/utils/schedules/utils.ts:50-70)
• findVolumeBackupById — same shape, via packages/server/src/utils/volume-backups/utils.ts:66,106

Worth considering separately: a guard so the next column added to application does not silently break
whichever query is closest to the limit — the failure mode is a runtime 54023 that no test or type check
catches, and the generic router error messages hide it.

Note on timing

Migration 0175 is not in any released tag yet (v0.29.13 ends at 0174_great_naoko), so no released
installation is affected. Fixing it before the next release means nobody ever sees it — after a release,
upgraded installations silently stop taking volume backups.

#4924 already fixes the rollback one; I can take the remaining three.

Will you send a PR to fix it?

Yes