feat(clickhouse): Add ability to use custom clickhouse user

[porthorian]

Why should this be accepted?

I was struggling to find out where I could define a clickhouse user, during my deployment. Wasn’t able to pinpoint in the documentation to do so, started looking into it and didn’t seem like there was a configuration option to do so?

I believe this addition can be beneficial for users that want to define their own clickhouse username for authentication to a clickhouse db

What this changes

• Adds an optional environment variable if CLICKHOUSE_USER is not empty and adds to the clickhouse client config for connection to the clickhouse db

Summary by CodeRabbit

• Chores
  • Improved database client initialization to more robustly handle environment-specific credentials (avoids using empty/whitespace username values and consolidates config assembly), reducing risk of connection issues during startup.

[vercel]

@porthorian is attempting to deploy a commit to the goldflag's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 89af6d69-e269-43fb-aa28-dd8a5a350811

📥 Commits

Reviewing files that changed from the base of the PR and between fc6d96e and 7322856.

📒 Files selected for processing (1)

• server/src/db/clickhouse/clickhouse.ts

---

📝 Walkthrough

Walkthrough

The ClickHouse client creation now builds a mutable clientConfig (typed as Parameters<typeof createClient>[0]), conditionally assigns clientConfig.username from process.env.CLICKHOUSE_USER only when non-empty, and then initializes the exported clickhouse client with that finalized config. Downstream usage is unchanged.

Changes

Cohort / File(s)	Summary
ClickHouse Client Configuration server/src/db/clickhouse/clickhouse.ts	Replaced inline config literal with a mutable clientConfig typed as Parameters<typeof createClient>[0]. Added conditional assignment of clientConfig.username only if process.env.CLICKHOUSE_USER is present and non-whitespace, then pass clientConfig to createClient to export clickhouse.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 I hopped to the config, tidy and neat,
A username checks in — then skips if discreet,
Whitespace be gone, let the client be fleet,
ClickHouse awaits with a soft little beat. 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main change: adding support for custom ClickHouse user configuration via environment variable.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

server/src/db/clickhouse/clickhouse.ts (1)

1-3: Avoid deep-importing ClickHouse internal types; use public API exports instead

Importing NodeClickHouseClientConfigOptions from @clickhouse/client/dist/config.js is not a supported public API—it couples this file to non-public package internals. Import from the package root or infer the type from createClient.

Also, imports should be grouped: external packages first (alphabetically), then internal imports. Currently, the internal import (../../lib/const.js) sits between two external imports.

♻️ Suggested refactor

 import { createClient } from "@clickhouse/client";
-import { IS_CLOUD } from "../../lib/const.js";
-import { NodeClickHouseClientConfigOptions } from "@clickhouse/client/dist/config.js";
+
+type ClickHouseClientConfig = Parameters<typeof createClient>[0];
+
+import { IS_CLOUD } from "../../lib/const.js";
 
-let clientConfig: NodeClickHouseClientConfigOptions = {
+let clientConfig: ClickHouseClientConfig = {
   url: process.env.CLICKHOUSE_HOST,
   database: process.env.CLICKHOUSE_DB,
   password: process.env.CLICKHOUSE_PASSWORD,
 };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/src/db/clickhouse/clickhouse.ts` around lines 1 - 3, The file imports
a non-public type NodeClickHouseClientConfigOptions from
"@clickhouse/client/dist/config.js" and misorders imports; remove the deep
import and instead use the public API types from the package root (or infer the
config type from createClient's signature/return) when declaring ClickHouse
config, and reorder imports so external packages (alphabetically, e.g.,
"@clickhouse/client" then others) come first and internal modules like IS_CLOUD
("../../lib/const.js") follow; update any references to
NodeClickHouseClientConfigOptions to use the public type or an inferred/locally
defined interface and keep createClient usage unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@server/src/db/clickhouse/clickhouse.ts`:
- Around line 11-13: The guard around setting clientConfig.username incorrectly
treats undefined as !== "" so username gets set when CLICKHOUSE_USER is unset;
change the condition on CLICKHOUSE_USER used before assigning
clientConfig.username (the check around process.env.CLICKHOUSE_USER and the
assignment to clientConfig.username) to only run when the env var is a non-empty
string (e.g., use a truthy/non-empty check such as if
(process.env.CLICKHOUSE_USER) or an explicit typeof/string and !== "" check) so
username is only set when CLICKHOUSE_USER is provided.

---

Nitpick comments:
In `@server/src/db/clickhouse/clickhouse.ts`:
- Around line 1-3: The file imports a non-public type
NodeClickHouseClientConfigOptions from "@clickhouse/client/dist/config.js" and
misorders imports; remove the deep import and instead use the public API types
from the package root (or infer the config type from createClient's
signature/return) when declaring ClickHouse config, and reorder imports so
external packages (alphabetically, e.g., "@clickhouse/client" then others) come
first and internal modules like IS_CLOUD ("../../lib/const.js") follow; update
any references to NodeClickHouseClientConfigOptions to use the public type or an
inferred/locally defined interface and keep createClient usage unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d243c402-8937-4903-8317-d02be4a192b3

📥 Commits

Reviewing files that changed from the base of the PR and between 28abe32 and fc6d96e.

📒 Files selected for processing (1)

• server/src/db/clickhouse/clickhouse.ts