refactor: get rid of pg queue app name env var#959
refactor: get rid of pg queue app name env var#959TylerHillery wants to merge 3 commits intomasterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Refactors Postgres connection tagging by removing the dedicated PG_QUEUE_APPLICATION_NAME configuration and reusing DATABASE_APPLICATION_NAME for the pg-boss/queue connection pool, simplifying how application names are set across DB clients.
Changes:
- Wire
databaseApplicationNameinto the queue (pg-boss)pg.Poolconfig asapplication_name. - Remove
pgQueueApplicationNamefromgetConfig()and its related env var (PG_QUEUE_APPLICATION_NAME). - Drop the
QueueDBconstructor fallback that previously injectedpgQueueApplicationName.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
src/internal/queue/queue.ts |
Passes databaseApplicationName as application_name for the queue pool. |
src/internal/queue/database.ts |
Removes implicit config defaulting for application_name. |
src/config.ts |
Removes pgQueueApplicationName from config type and env parsing. |
.env.sample |
Removes PG_QUEUE_APPLICATION_NAME from the sample environment file. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| databaseApplicationName: | ||
| getOptionalConfigFromEnv('DATABASE_APPLICATION_NAME') || | ||
| `Supabase Storage API ${getOptionalConfigFromEnv('VERSION') || '0.0.0'}`, |
There was a problem hiding this comment.
Removing PG_QUEUE_APPLICATION_NAME is a breaking configuration change for existing deployments that currently set it to tag PgBoss/queue connections. Consider supporting PG_QUEUE_APPLICATION_NAME as a deprecated fallback/alias (e.g., only if DATABASE_APPLICATION_NAME is unset) or emitting a clear startup warning so operators understand why connection tagging changed.
| databaseApplicationName: | |
| getOptionalConfigFromEnv('DATABASE_APPLICATION_NAME') || | |
| `Supabase Storage API ${getOptionalConfigFromEnv('VERSION') || '0.0.0'}`, | |
| databaseApplicationName: (() => { | |
| const databaseApplicationName = getOptionalConfigFromEnv('DATABASE_APPLICATION_NAME') | |
| if (databaseApplicationName) { | |
| return databaseApplicationName | |
| } | |
| const legacyQueueApplicationName = getOptionalConfigFromEnv('PG_QUEUE_APPLICATION_NAME') | |
| if (legacyQueueApplicationName) { | |
| console.warn( | |
| 'PG_QUEUE_APPLICATION_NAME is deprecated; please migrate to DATABASE_APPLICATION_NAME. ' + | |
| 'Support for PG_QUEUE_APPLICATION_NAME may be removed in a future release.' | |
| ) | |
| return legacyQueueApplicationName | |
| } | |
| return `Supabase Storage API ${getOptionalConfigFromEnv('VERSION') || '0.0.0'}` | |
| })(), |
Pull Request Test Coverage Report for Build 23847839555Details
💛 - Coveralls |
| "type": "prometheus", | ||
| "uid": "local_prometheus" | ||
| }, | ||
| "expr": "pgbouncer_up{job=\"discovered-internal-storage-pgbouncer\", instance=~\"$instance\"}", |
There was a problem hiding this comment.
this won't work here because job name isn't matching
There was a problem hiding this comment.
it seems we're also running different version of exporter
|
I think env changes are fine. If you can want, we can merge it and add the setup/dashboard separately. |
What kind of change does this PR introduce?
Refactor , to remove the redundant
PG_QUEUE_APPLICATION_NAME.What is the current behavior?
Currently there are two variables set that determine the application name that is used when connecting to postgres
PG_QUEUE_APPLICAITON_NAMEwhich was used during the connection to the internal pg pool and MT DBDB_APPLICATION_NAMEwhich was used to connect to the tenant DBWhat is the new behavior?
PG_QUEUE_APPLICATION_NAMEis redundant for what we are trying to accomplish which is distinguishing the worker connections from the API connections, we only need theDB_APPLICATION_NAMEto do this.