Support system database sharing (application names)

[devhawk]

Closes #468. Port of python#809, ts#1326, and go #444/#445.

Every DBOS object — workflows, steps, queues, schedules, application versions — records the application that owns it, so several applications can share one system database in isolation, or interoperate deliberately by naming each other's objects.

NULL means unclaimed. The columns are added nullable with no default, so every pre-existing row, and every row written by an SDK that does not know the column, belongs to all of them. Reads match application_name = ? OR application_name IS NULL throughout. That is what makes the migration safe, and also what makes the isolation one-directional: naming your applications hides them from each other, but not from an executor that ignores the column.

Schema

Migrations 100–107, the start of a cross-SDK shared history: from index 100 on, every SDK defines the same migration at the same index. This language's own history (1–47) is padded out to 99, and both the runner and dbos migrate --print skip the padding without a round trip each, recording it in a single write.

#
100–104	application_name on workflow_status, queues, workflow_schedules, application_versions, operation_outputs
105	enqueue_workflow gains a trailing application_name; every parameter is defaulted, so callers that omit it still resolve to it
106–107	the partial unique index pair that replaces version_name's global uniqueness (which is not dropped — not until every SDK reaching a shared database is past 107)

What is scoped

Listings (workflows, queues, schedules, versions, aggregates, metrics), the queue dequeue and its rate-limit and concurrency counts, the latest-version lookup, the delayed-workflow and garbage-collection sweeps, and the debounce holder lookup. Recovery follows from the workflow listing — which matters, because executor_id defaults to the literal local in all four SDKs, so two unnamed applications sharing a database would otherwise each treat the other's PENDING workflows as their own to recover.

Deliberately not scoped: anything addressed by workflow ID. A fork is the forking application's own work, steps included.

Registering a queue, schedule, or application version under a name another application holds raises DBOSApplicationNameConflictException — names are shared address space, so a collision is not ours to resolve.

Behaviour changes worth knowing

• The application name is hashed into the computed application version, so two applications built from one jar do not collide on a single version row. Existing deployments therefore compute a new version on upgrade, as they do in Python, TypeScript, and Go.
• DBOSClient takes an optional application name; without one it owns nothing and sees every application's rows.
• The conductor protocol carries application_name on workflow, queue, schedule, and version rows, and accepts it as a filter on the list and aggregate requests. A Conductor that predates the field sends nothing, which leaves every listing scoped to the application.

Not included

rename-application (re-owning rows after a rename, or adopting unclaimed ones) is a follow-up, matching Go. Until it lands, the collision error points at the Python or TypeScript CLI, which operates on the shared system database whatever wrote the rows.

Testing

New ApplicationNameTest runs two applications against one system database: stamping across all five tables, listing isolation and the explicit cross-application filter, unclaimed rows visible to both, dequeue isolation, fork ownership, the three collision errors, version scoping, and a nameless client. MigrationManagerTest covers upgrading a database recorded at 47 through the padding to 107. Full suite green.

🤖 Generated with Claude Code