Conversation
…NSRainbow application
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
🦋 Changeset detectedLatest commit: 75e72f8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughCentralizes ENSRainbow configuration with Zod schemas and a runtime Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant SDK as "SDK Client"
participant Server as "ENSRainbow API"
participant DB as "Database / Label store"
participant Builder as "buildENSRainbowPublicConfig"
SDK->>Server: GET /v1/config
Server->>DB: getServerLabelSet() (cached)
Server->>DB: labelCount() (startup-cached)
DB-->>Server: labelSet, count
Server->>Builder: assemble public config (version, labelSet, count)
Builder-->>Server: ENSRainbowPublicConfig
Server-->>SDK: 200 + ENSRainbowPublicConfig
sequenceDiagram
autonumber
participant CLI as "CLI"
participant ConfigBuilder as "buildConfigFromEnvironment"
participant Zod as "Zod schemas"
participant Process as "process"
CLI->>ConfigBuilder: request config from env
ConfigBuilder->>Zod: parse & validate environment -> ENSRainbowConfig
Zod-->>ConfigBuilder: validation result
alt valid
ConfigBuilder-->>CLI: return ENSRainbowConfig
CLI->>CLI: continue startup (serve/ingest) using config
else invalid
ConfigBuilder->>Process: log errors (pretty)
Process->>Process: exit non-zero
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In `@apps/ensrainbow/src/config/config.schema.ts`:
- Around line 65-71: The current ternary for labelSet uses a truthy check
(env.LABEL_SET_ID || env.LABEL_SET_VERSION) which treats empty strings as
missing; change the condition to explicit undefined checks so an empty string is
treated as a provided value and validation will run — e.g. replace the condition
with (env.LABEL_SET_ID !== undefined || env.LABEL_SET_VERSION !== undefined) and
still return the object with labelSetId: env.LABEL_SET_ID and labelSetVersion:
env.LABEL_SET_VERSION when true; keep the symbol name labelSet and the env keys
env.LABEL_SET_ID / env.LABEL_SET_VERSION so locators remain obvious.
- Around line 33-36: The schema currently calls getDefaultDataDir() at module
load in ENSRainbowConfigSchema (dataDir:
DataDirSchema.default(getDefaultDataDir())), capturing process.cwd() too early;
remove the eager default from ENSRainbowConfigSchema and instead handle lazy
evaluation in buildConfigFromEnvironment by supplying dataDir: env.DATA_DIR ??
getDefaultDataDir() when parsing/building the config, keeping
ENSRainbowConfigSchema (and DataDirSchema/PortSchema) purely declarative and
ensuring getDefaultDataDir() runs only at build time.
- Around line 18-24: The path transform in the config schema currently treats
paths starting with "/" as absolute; update the transform used on the config
field to use Node's path.isAbsolute(path) instead of path.startsWith("/"), and
ensure the Node "path" module is imported (or isAbsolute is referenced)
alongside the existing join and process.cwd() usage in the transform callback so
Windows absolute paths like "C:\..." are detected correctly and returned
unchanged.
- Around line 73-83: Replace the terminal process.exit(1) in the catch block
with throwing a descriptive error so callers can handle failures; specifically,
inside the catch for buildConfigFromEnvironment (or whatever function constructs
ENSRainbowConfig) throw a custom error (e.g., ConfigBuildError) or rethrow the
existing Error with context including the prettified ZodError output and the
message "Failed to build ENSRainbowConfig", while keeping the existing logger
calls for ZodError and generic Error; move any process.exit(1) behavior out to
the CLI/entrypoint so tests can catch the thrown error and decide whether to
exit.
In `@apps/ensrainbow/src/config/validations.ts`:
- Around line 7-10: The current type ZodCheckFnInput<T> uses the internal
z.core.ParsePayload<T>; change it to rely on Zod's documented types or a simple
explicit input shape instead: remove z.core.ParsePayload and either use the
public helper z.input with a Zod type (e.g., z.input<z.ZodType<T>>) or replace
ZodCheckFnInput<T> with a small explicit interface/alias (e.g., unknown or
Record<string, any> or a narrow shape your check expects) so the code no longer
depends on the unstable z.core namespace; update any usages of ZodCheckFnInput
to match the new public type.
In `@apps/ensrainbow/src/lib/env.ts`:
- Around line 7-10: The getEnvPort function unsafely asserts process.env as
ENSRainbowEnvironment and rebuilds the full config on every call; remove the
type assertion and instead import the ENSRainbowConfig type (import type {
ENSRainbowConfig } ...) and let buildConfigFromEnvironment validate process.env
at runtime, receiving an ENSRainbowConfig result; then read and return
config.port. Also memoize the built config in a module-level variable so
getEnvPort calls reuse the same config instead of reconstructing it each time
(references: getEnvPort, buildConfigFromEnvironment, ENSRainbowEnvironment,
ENSRainbowConfig).
There was a problem hiding this comment.
Pull request overview
Introduces a Zod-based, centralized environment configuration builder for the ENSRainbow app, aligning it with the configuration patterns used in other apps in the monorepo.
Changes:
- Added ENSRainbow config schema, environment types, defaults, and cross-field validations.
- Updated ENSRainbow CLI/env port handling to use the new config builder and centralized defaults.
- Tightened shared
PortSchemavalidation to require integer ports; addedzodas a direct ENSRainbow dependency.
Reviewed changes
Copilot reviewed 11 out of 12 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| pnpm-lock.yaml | Adds zod to the ENSRainbow importer lock entry. |
| packages/ensnode-sdk/src/shared/config/zod-schemas.ts | Updates shared PortSchema to require integer ports. |
| apps/ensrainbow/src/lib/env.ts | Switches env port resolution to buildConfigFromEnvironment(...). |
| apps/ensrainbow/src/config/validations.ts | Adds ENSRainbow-specific invariant validation for schema version. |
| apps/ensrainbow/src/config/types.ts | Re-exports ENSRainbow config type. |
| apps/ensrainbow/src/config/index.ts | Adds a config module entrypoint exporting types/functions/defaults. |
| apps/ensrainbow/src/config/environment.ts | Defines typed raw environment shape for ENSRainbow. |
| apps/ensrainbow/src/config/defaults.ts | Centralizes ENSRainbow default port and data dir. |
| apps/ensrainbow/src/config/config.schema.ts | Adds ENSRainbow Zod schema + config builder with logging/exit-on-failure behavior. |
| apps/ensrainbow/src/cli.ts | Uses new defaults module for data dir default; continues using env-derived port. |
| apps/ensrainbow/src/cli.test.ts | Updates port tests to reflect process-exit behavior on invalid PORT values. |
| apps/ensrainbow/package.json | Adds zod as an explicit dependency for ENSRainbow. |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
… for environment variable handling
…d of environment variable
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 17 out of 19 changed files in this pull request and generated 4 comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ate output structure
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 17 out of 19 changed files in this pull request and generated 1 comment.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 17 out of 19 changed files in this pull request and generated 1 comment.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
lightwalker-eth
left a comment
There was a problem hiding this comment.
@djstrong Thanks. Sharing some preliminary feedback.
apps/ensrainbow/src/config/types.ts
Outdated
| * - If only one of LABEL_SET_ID or LABEL_SET_VERSION is provided in the environment, | ||
| * configuration parsing will fail with a clear error message | ||
| */ | ||
| labelSet?: Required<EnsRainbowClientLabelSet>; |
There was a problem hiding this comment.
Shouldn't this be a server label set?
apps/ensrainbow/src/config/types.ts
Outdated
| dbSchemaVersion: number; | ||
|
|
||
| /** | ||
| * Optional label set configuration that specifies which label set to use. |
There was a problem hiding this comment.
Why is this optional? I assume it should be required?
apps/ensrainbow/src/config/types.ts
Outdated
| * Both `labelSetId` and `labelSetVersion` must be provided together to create a "fully pinned" | ||
| * label set reference, ensuring deterministic and reproducible label healing. | ||
| * | ||
| * If not provided, ENSRainbow will start without any label set loaded, and label healing |
There was a problem hiding this comment.
Not sure what "the management API" is?
I assume ENSRainbow should refuse to start if this is undefined or a valid server label set is not configured?
apps/ensrainbow/src/config/types.ts
Outdated
| * | ||
| * Examples: | ||
| * - `{ labelSetId: "subgraph", labelSetVersion: 0 }` - The legacy subgraph label set | ||
| * - `{ labelSetId: "ensip-15", labelSetVersion: 1 }` - ENSIP-15 normalized labels |
There was a problem hiding this comment.
I assume better to use searchlight for this other example?
apps/ensrainbow/src/config/types.ts
Outdated
| * | ||
| * Invariants: | ||
| * - If provided, both `labelSetId` and `labelSetVersion` must be defined | ||
| * - `labelSetId` must be 1-50 characters, containing only lowercase letters (a-z) and hyphens (-) |
There was a problem hiding this comment.
We shouldn't repeat the definitions of ideas in lots of places. We already define what a label set id is somewhere else. This makes our code very difficult to maintain.
apps/ensrainbow/src/config/types.ts
Outdated
| * This prevents version mismatches between the codebase and the database schema, which could | ||
| * lead to data corruption or runtime errors. | ||
| * | ||
| * Default: {@link DB_SCHEMA_VERSION} (currently 3) |
There was a problem hiding this comment.
Defaults should not be documented here. Those ideas belong in a different layer.
apps/ensrainbow/src/config/types.ts
Outdated
| * | ||
| * Invariants: | ||
| * - Must be a valid port number (1-65535) | ||
| * - Must not be already in use by another process |
There was a problem hiding this comment.
This idea belongs at a different layer.
apps/ensrainbow/src/config/types.ts
Outdated
| * Default: {@link DB_SCHEMA_VERSION} (currently 3) | ||
| * | ||
| * Invariants: | ||
| * - Must be a positive integer |
There was a problem hiding this comment.
We need to:
- Define a type alias for
DbSchemaVersion. - Document this invariant on the type alias.
- Use this type alias wherever it is relevant.
- Remove duplicate definitions of this invariant. The documentation of this invariant should only happen once on the type alias otherwise its so difficult to maintain.
apps/ensrainbow/src/config/types.ts
Outdated
| * - Must be a valid port number (1-65535) | ||
| * - Must not be already in use by another process | ||
| */ | ||
| port: number; |
There was a problem hiding this comment.
We need to:
- Define a type alias for
PortNumber. - Document relevant invariants on the type alias.
- Use this type alias wherever it is relevant.
- Remove duplicate definitions of this invariant. The documentation of this invariant should only happen once on the type alias otherwise its so difficult to maintain.
apps/ensrainbow/src/config/types.ts
Outdated
| /** | ||
| * Optional label set configuration that specifies which label set to use. | ||
| * | ||
| * A label set defines which labels (domain name segments) are available for label healing. |
There was a problem hiding this comment.
This idea does not belong here! We are repeating the documentation of ideas in way too many places which quickly becomes impossible to maintain!
…clarity and update related types and functions
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/ensrainbow/src/config/config.schema.ts`:
- Around line 56-120: The LABEL_SET_ID and LABEL_SET_VERSION values are
forwarded raw in buildConfigFromEnvironment's envToConfigSchema.transform even
though presence checks use trimmed values; update the transform in
envToConfigSchema (inside buildConfigFromEnvironment) to trim LABEL_SET_ID and
LABEL_SET_VERSION before constructing the labelSet object (e.g., compute const
id = env.LABEL_SET_ID?.trim(); const ver = env.LABEL_SET_VERSION?.trim(); and
use those when setting labelSet), so downstream validation sees cleaned values;
keep existing hasValue checks as-is and only change the transform that builds
labelSet/returns the config.
| export function buildConfigFromEnvironment(env: ENSRainbowEnvironment): ENSRainbowEnvConfig { | ||
| try { | ||
| const envToConfigSchema = z | ||
| .object({ | ||
| PORT: z.string().optional(), | ||
| DATA_DIR: z.string().optional(), | ||
| DB_SCHEMA_VERSION: z.string().optional(), | ||
| LABEL_SET_ID: z.string().optional(), | ||
| LABEL_SET_VERSION: z.string().optional(), | ||
| }) | ||
| .check((ctx) => { | ||
| const { value: env } = ctx; | ||
| const hasLabelSetId = hasValue(env.LABEL_SET_ID); | ||
| const hasLabelSetVersion = hasValue(env.LABEL_SET_VERSION); | ||
|
|
||
| if (hasLabelSetId && !hasLabelSetVersion) { | ||
| ctx.issues.push({ | ||
| code: "custom", | ||
| path: ["LABEL_SET_VERSION"], | ||
| input: env, | ||
| message: | ||
| "LABEL_SET_ID is set but LABEL_SET_VERSION is missing. Both LABEL_SET_ID and LABEL_SET_VERSION must be provided together, or neither.", | ||
| }); | ||
| } | ||
|
|
||
| if (!hasLabelSetId && hasLabelSetVersion) { | ||
| ctx.issues.push({ | ||
| code: "custom", | ||
| path: ["LABEL_SET_ID"], | ||
| input: env, | ||
| message: | ||
| "LABEL_SET_VERSION is set but LABEL_SET_ID is missing. Both LABEL_SET_ID and LABEL_SET_VERSION must be provided together, or neither.", | ||
| }); | ||
| } | ||
| }) | ||
| .transform((env) => { | ||
| const hasLabelSetId = hasValue(env.LABEL_SET_ID); | ||
| const hasLabelSetVersion = hasValue(env.LABEL_SET_VERSION); | ||
|
|
||
| const labelSet = | ||
| hasLabelSetId && hasLabelSetVersion | ||
| ? { | ||
| labelSetId: env.LABEL_SET_ID, | ||
| labelSetVersion: env.LABEL_SET_VERSION, | ||
| } | ||
| : undefined; | ||
|
|
||
| return { | ||
| port: env.PORT, | ||
| dataDir: env.DATA_DIR, | ||
| dbSchemaVersion: env.DB_SCHEMA_VERSION, | ||
| labelSet, | ||
| }; | ||
| }); | ||
|
|
||
| const configInput = envToConfigSchema.parse(env); | ||
| return ENSRainbowConfigSchema.parse(configInput); | ||
| } catch (error) { | ||
| if (error instanceof ZodError) { | ||
| throw new Error(`Failed to parse environment configuration: \n${prettifyError(error)}\n`); | ||
| } | ||
|
|
||
| throw error; | ||
| } | ||
| } |
There was a problem hiding this comment.
Trim label set env values before building labelSet.
You already use trim() for presence checks, but you forward raw values. Whitespace around env values can sneak through and cause confusing downstream validation failures. Trim once and reuse.
♻️ Proposed fix
.transform((env) => {
- const hasLabelSetId = hasValue(env.LABEL_SET_ID);
- const hasLabelSetVersion = hasValue(env.LABEL_SET_VERSION);
+ const labelSetId = env.LABEL_SET_ID?.trim();
+ const labelSetVersion = env.LABEL_SET_VERSION?.trim();
+ const hasLabelSetId = hasValue(labelSetId);
+ const hasLabelSetVersion = hasValue(labelSetVersion);
const labelSet =
hasLabelSetId && hasLabelSetVersion
? {
- labelSetId: env.LABEL_SET_ID,
- labelSetVersion: env.LABEL_SET_VERSION,
+ labelSetId,
+ labelSetVersion,
}
: undefined;🤖 Prompt for AI Agents
In `@apps/ensrainbow/src/config/config.schema.ts` around lines 56 - 120, The
LABEL_SET_ID and LABEL_SET_VERSION values are forwarded raw in
buildConfigFromEnvironment's envToConfigSchema.transform even though presence
checks use trimmed values; update the transform in envToConfigSchema (inside
buildConfigFromEnvironment) to trim LABEL_SET_ID and LABEL_SET_VERSION before
constructing the labelSet object (e.g., compute const id =
env.LABEL_SET_ID?.trim(); const ver = env.LABEL_SET_VERSION?.trim(); and use
those when setting labelSet), so downstream validation sees cleaned values; keep
existing hasValue checks as-is and only change the transform that builds
labelSet/returns the config.
…ed tests for simplification
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 21 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Comments suppressed due to low confidence (1)
apps/ensrainbow/src/config/env-config.test.ts:286
- There are two test files with nearly identical content:
env-config.test.ts(286 lines) andconfig.schema.test.ts(316 lines). Both files testbuildConfigFromEnvironmentwith the same test cases. The only difference is thatconfig.schema.test.tsalso includes tests forbuildENSRainbowPublicConfig. This appears to be unintentional duplication. Consider removingenv-config.test.tsand keeping onlyconfig.schema.test.tswhich has the more complete test coverage.
import { isAbsolute, resolve } from "node:path";
import { describe, expect, it, vi } from "vitest";
import { DB_SCHEMA_VERSION } from "@/lib/database";
import { buildConfigFromEnvironment } from "./config.schema";
import { ENSRAINBOW_DEFAULT_PORT, getDefaultDataDir } from "./defaults";
import type { ENSRainbowEnvironment } from "./environment";
vi.mock("@/utils/logger", () => ({
logger: {
error: vi.fn(),
},
}));
describe("buildConfigFromEnvironment", () => {
describe("Success cases", () => {
it("returns a valid config with all defaults when environment is empty", () => {
const env: ENSRainbowEnvironment = {};
const config = buildConfigFromEnvironment(env);
expect(config).toStrictEqual({
port: ENSRAINBOW_DEFAULT_PORT,
dataDir: getDefaultDataDir(),
dbSchemaVersion: DB_SCHEMA_VERSION,
});
});
it("applies custom port when PORT is set", () => {
const env: ENSRainbowEnvironment = {
PORT: "5000",
};
const config = buildConfigFromEnvironment(env);
expect(config.port).toBe(5000);
expect(config.dataDir).toBe(getDefaultDataDir());
});
it("applies custom DATA_DIR when set", () => {
const customDataDir = "/var/lib/ensrainbow/data";
const env: ENSRainbowEnvironment = {
DATA_DIR: customDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(config.dataDir).toBe(customDataDir);
});
it("normalizes relative DATA_DIR to absolute path", () => {
const relativeDataDir = "my-data";
const env: ENSRainbowEnvironment = {
DATA_DIR: relativeDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(isAbsolute(config.dataDir)).toBe(true);
expect(config.dataDir).toBe(resolve(process.cwd(), relativeDataDir));
});
it("resolves nested relative DATA_DIR correctly", () => {
const relativeDataDir = "./data/ensrainbow/db";
const env: ENSRainbowEnvironment = {
DATA_DIR: relativeDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(isAbsolute(config.dataDir)).toBe(true);
expect(config.dataDir).toBe(resolve(process.cwd(), relativeDataDir));
});
it("preserves absolute DATA_DIR", () => {
const absoluteDataDir = "/absolute/path/to/data";
const env: ENSRainbowEnvironment = {
DATA_DIR: absoluteDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(config.dataDir).toBe(absoluteDataDir);
});
it("applies DB_SCHEMA_VERSION when set and matches code version", () => {
const env: ENSRainbowEnvironment = {
DB_SCHEMA_VERSION: DB_SCHEMA_VERSION.toString(),
};
const config = buildConfigFromEnvironment(env);
expect(config.dbSchemaVersion).toBe(DB_SCHEMA_VERSION);
});
it("defaults DB_SCHEMA_VERSION to code version when not set", () => {
const env: ENSRainbowEnvironment = {};
const config = buildConfigFromEnvironment(env);
expect(config.dbSchemaVersion).toBe(DB_SCHEMA_VERSION);
});
it("handles all valid configuration options together", () => {
const env: ENSRainbowEnvironment = {
PORT: "4444",
DATA_DIR: "/opt/ensrainbow/data",
DB_SCHEMA_VERSION: DB_SCHEMA_VERSION.toString(),
};
const config = buildConfigFromEnvironment(env);
expect(config).toStrictEqual({
port: 4444,
dataDir: "/opt/ensrainbow/data",
dbSchemaVersion: DB_SCHEMA_VERSION,
});
});
});
describe("Validation errors", () => {
it("fails when PORT is not a number", () => {
const env: ENSRainbowEnvironment = {
PORT: "not-a-number",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when PORT is a float", () => {
const env: ENSRainbowEnvironment = {
PORT: "3000.5",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when PORT is less than 1", () => {
const env: ENSRainbowEnvironment = {
PORT: "0",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when PORT is negative", () => {
const env: ENSRainbowEnvironment = {
PORT: "-100",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when PORT is greater than 65535", () => {
const env: ENSRainbowEnvironment = {
PORT: "65536",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when DATA_DIR is empty string", () => {
const env: ENSRainbowEnvironment = {
DATA_DIR: "",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when DATA_DIR is only whitespace", () => {
const env: ENSRainbowEnvironment = {
DATA_DIR: " ",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when DB_SCHEMA_VERSION is not a number", () => {
const env: ENSRainbowEnvironment = {
DB_SCHEMA_VERSION: "not-a-number",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
it("fails when DB_SCHEMA_VERSION is a float", () => {
const env: ENSRainbowEnvironment = {
DB_SCHEMA_VERSION: "3.5",
};
expect(() => buildConfigFromEnvironment(env)).toThrow();
});
});
describe("Invariant: DB_SCHEMA_VERSION must match code version", () => {
it("fails when DB_SCHEMA_VERSION does not match code version", () => {
const wrongVersion = DB_SCHEMA_VERSION + 1;
const env: ENSRainbowEnvironment = {
DB_SCHEMA_VERSION: wrongVersion.toString(),
};
expect(() => buildConfigFromEnvironment(env)).toThrow(/DB_SCHEMA_VERSION mismatch/);
});
it("passes when DB_SCHEMA_VERSION matches code version", () => {
const env: ENSRainbowEnvironment = {
DB_SCHEMA_VERSION: DB_SCHEMA_VERSION.toString(),
};
const config = buildConfigFromEnvironment(env);
expect(config.dbSchemaVersion).toBe(DB_SCHEMA_VERSION);
});
it("passes when DB_SCHEMA_VERSION defaults to code version", () => {
const env: ENSRainbowEnvironment = {};
const config = buildConfigFromEnvironment(env);
expect(config.dbSchemaVersion).toBe(DB_SCHEMA_VERSION);
});
});
describe("Edge cases", () => {
it("handles PORT at minimum valid value (1)", () => {
const env: ENSRainbowEnvironment = {
PORT: "1",
};
const config = buildConfigFromEnvironment(env);
expect(config.port).toBe(1);
});
it("handles PORT at maximum valid value (65535)", () => {
const env: ENSRainbowEnvironment = {
PORT: "65535",
};
const config = buildConfigFromEnvironment(env);
expect(config.port).toBe(65535);
});
it("trims whitespace from DATA_DIR", () => {
const dataDir = "/my/path/to/data";
const env: ENSRainbowEnvironment = {
DATA_DIR: ` ${dataDir} `,
};
const config = buildConfigFromEnvironment(env);
expect(config.dataDir).toBe(dataDir);
});
it("handles DATA_DIR with .. (parent directory)", () => {
const relativeDataDir = "../data";
const env: ENSRainbowEnvironment = {
DATA_DIR: relativeDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(isAbsolute(config.dataDir)).toBe(true);
expect(config.dataDir).toBe(resolve(process.cwd(), relativeDataDir));
});
it("handles DATA_DIR with ~ (not expanded, treated as relative)", () => {
// Note: The config schema does NOT expand ~ to home directory
// It would be treated as a relative path
const tildeDataDir = "~/data";
const env: ENSRainbowEnvironment = {
DATA_DIR: tildeDataDir,
};
const config = buildConfigFromEnvironment(env);
expect(isAbsolute(config.dataDir)).toBe(true);
// ~ is treated as a directory name, not home expansion
expect(config.dataDir).toBe(resolve(process.cwd(), tildeDataDir));
});
});
});
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/ensrainbow/src/config/types.ts`:
- Around line 1-17: The import of AbsolutePathSchemaBase and
DbSchemaVersionSchemaBase is currently type-only which breaks the z.infer<typeof
...> uses because typeof requires runtime values; update the import so those two
symbols are imported as real values (remove the `type`-only import for
AbsolutePathSchemaBase and DbSchemaVersionSchemaBase) while keeping other purely
type imports (e.g., z, PortNumber) as type imports, so that AbsolutePath and
DbSchemaVersion can use z.infer<typeof AbsolutePathSchemaBase> and
z.infer<typeof DbSchemaVersionSchemaBase> successfully.
| import type { z } from "zod/v4"; | ||
|
|
||
| import type { PortNumber } from "@ensnode/ensnode-sdk/internal"; | ||
|
|
||
| import type { AbsolutePathSchemaBase, DbSchemaVersionSchemaBase } from "./config.schema"; | ||
|
|
||
| /** | ||
| * Absolute filesystem path. | ||
| * Inferred from {@link AbsolutePathSchemaBase} - see that schema for invariants. | ||
| */ | ||
| export type AbsolutePath = z.infer<typeof AbsolutePathSchemaBase>; | ||
|
|
||
| /** | ||
| * Database schema version number. | ||
| * Inferred from {@link DbSchemaVersionSchemaBase} - see that schema for invariants. | ||
| */ | ||
| export type DbSchemaVersion = z.infer<typeof DbSchemaVersionSchemaBase>; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the config.schema file
find . -name "config.schema*" -type fRepository: namehash/ensnode
Length of output: 291
🏁 Script executed:
# Search for AbsolutePathSchemaBase and DbSchemaVersionSchemaBase definitions
rg "AbsolutePathSchemaBase|DbSchemaVersionSchemaBase" --type ts --type tsx -B 2 -A 2Repository: namehash/ensnode
Length of output: 87
🏁 Script executed:
# Read the config.schema.ts file to see exports
cat -n ./apps/ensrainbow/src/config/config.schema.ts | head -100Repository: namehash/ensnode
Length of output: 3345
🏁 Script executed:
# Search for the schema definitions more carefully
rg "AbsolutePathSchemaBase|DbSchemaVersionSchemaBase" -B 2 -A 2Repository: namehash/ensnode
Length of output: 2499
🏁 Script executed:
# Check if the types.ts file has any TypeScript compilation errors
# Look for build configuration
find . -name "tsconfig.json" -o -name "tsconfig*.json" | head -5Repository: namehash/ensnode
Length of output: 218
🏁 Script executed:
# Check if there's any build or type-check output that might show errors
# Also verify by looking at the actual import/export statements carefully
cat -n ./apps/ensrainbow/src/config/types.tsRepository: namehash/ensnode
Length of output: 1019
Type-only import breaks z.infer type queries.
AbsolutePathSchemaBase and DbSchemaVersionSchemaBase are runtime values exported as const from config.schema.ts, but imported with import type in line 5. Using typeof on type-only imports is invalid—TypeScript will fail to compile. Import them as values instead:
Fix
-import type { AbsolutePathSchemaBase, DbSchemaVersionSchemaBase } from "./config.schema";
+import { AbsolutePathSchemaBase, DbSchemaVersionSchemaBase } from "./config.schema";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import type { z } from "zod/v4"; | |
| import type { PortNumber } from "@ensnode/ensnode-sdk/internal"; | |
| import type { AbsolutePathSchemaBase, DbSchemaVersionSchemaBase } from "./config.schema"; | |
| /** | |
| * Absolute filesystem path. | |
| * Inferred from {@link AbsolutePathSchemaBase} - see that schema for invariants. | |
| */ | |
| export type AbsolutePath = z.infer<typeof AbsolutePathSchemaBase>; | |
| /** | |
| * Database schema version number. | |
| * Inferred from {@link DbSchemaVersionSchemaBase} - see that schema for invariants. | |
| */ | |
| export type DbSchemaVersion = z.infer<typeof DbSchemaVersionSchemaBase>; | |
| import type { z } from "zod/v4"; | |
| import type { PortNumber } from "@ensnode/ensnode-sdk/internal"; | |
| import { AbsolutePathSchemaBase, DbSchemaVersionSchemaBase } from "./config.schema"; | |
| /** | |
| * Absolute filesystem path. | |
| * Inferred from {`@link` AbsolutePathSchemaBase} - see that schema for invariants. | |
| */ | |
| export type AbsolutePath = z.infer<typeof AbsolutePathSchemaBase>; | |
| /** | |
| * Database schema version number. | |
| * Inferred from {`@link` DbSchemaVersionSchemaBase} - see that schema for invariants. | |
| */ | |
| export type DbSchemaVersion = z.infer<typeof DbSchemaVersionSchemaBase>; |
🤖 Prompt for AI Agents
In `@apps/ensrainbow/src/config/types.ts` around lines 1 - 17, The import of
AbsolutePathSchemaBase and DbSchemaVersionSchemaBase is currently type-only
which breaks the z.infer<typeof ...> uses because typeof requires runtime
values; update the import so those two symbols are imported as real values
(remove the `type`-only import for AbsolutePathSchemaBase and
DbSchemaVersionSchemaBase) while keeping other purely type imports (e.g., z,
PortNumber) as type imports, so that AbsolutePath and DbSchemaVersion can use
z.infer<typeof AbsolutePathSchemaBase> and z.infer<typeof
DbSchemaVersionSchemaBase> successfully.
Related to #1407
Lite PR
Summary
/v1/configendpoint returning public config (version, label set, records count) and deprecated/v1/versionWhy
Testing
config.schema.test.ts) covering success cases, validation errors, invariants, and edge cases/v1/configendpoint in server command testsNotes for Reviewer (Optional)
/v1/versionendpoint is deprecated but still functional for backward compatibilityPre-Review Checklist (Blocking)