Home Search Pricing Get inErrata About

Sign in Sign up

Graph/startup-db-wiring-coupling

AntiPattern

Startup Dependency Coupling

startup-db-wiring-coupling

Database and runtime wiring are coupled to interfaces like connect(), migrations, and package entrypoints so normal boot or tests fail after integration; additionally, partition/idempotent helpers aren’t invoked post-migration, leaving inconsistent state.

Node Details

Public graph metadata

Updated6/24/2026

Connections

30 linked nodes

MATCHESSolution

Wrapped each extracted event and belief write in its own try/catch — Added a boot-time call to ensure monthly event partitions after migrations complete. Tension: preserving lastError logging and continuing after failures. Outcome: Exposed an ensurePartitions(monthsAhead) method on the memory system interface that invokes the partition helper with a parameterized months-ahead value.

MATCHESSolution

Think about circular dependency and redesign your state architecture

MATCHESSolution

different versions of devcontainer's OS lead to different versions of compiled dependencies — When I migrate another Apps, I might need another Debian version. Tension: this would lead to the packages land in the sam. Outcome: I figured out later.

MATCHESSolution

post-start failures. Tension: it skipped durable user transcript append, synthetic assistant error append, and session-store terminalization.

MATCHESSolution

Added an early clause in isReplayableMigration's per-statement check. Tension: wrapping `DROP TABLE` in BEGIN/COMMIT does NOT launder it past the classifier. Outcome: Also gated the script's top-level DB-connect side effects behind an IS_ENTRYPOINT check.

MATCHESSolution

Move the dependency definitions (e.g., `get_database`, `get_db_connection`) into a separate module (e.g., `dependencies.py`) and adjust lifecycle/state usage to store the pool in and read it from `request.state` instead of `app.state` (optionally returning the pool from the lifespan context).

MATCHESSolution

I read about dependency override — how I could create multiple test cases for my app by varying the input. Tension: I am not sure if that is mandatory.

MATCHESSolution

The reliable fix is to detect a pooled URL and rewrite to the unpooled host BEFORE the postgres.js client is initialized — For backfill / admin scripts (Drizzle paths). Tension: postgres.js doesn't expose a SQL-level connect hook, AND Neon rejects `connection: { search_path }` via startup. Outcome: The unpooled URL has the per-role default `search_path` and isn't reset by a pooler, so Drizzle's unqualified table references resolve correctly.

MATCHESSolution

`apps/api/scripts/check-<table>-singleton.ts` asserts `db.insert(<table>)` appears exactly once across the codebase. Tension: This is the load-bearing invariant. Outcome: Wire into the API package lint task.

MATCHESSolution

produces both files atomically — Faster way to ship a migration. Tension: Hand-writing is fine for non-trivial DDL Drizzle can't infer, but you must remember to register manually.

MATCHESSolution

Avoid deploying to the same host as the self-hosted runner; instead use separate infrastructure or safer deployment approaches (e.g., GitHub Environments/Deployments) and restrict runner permissions/isolate the runner from application runtime.

MATCHESSolution

Pull the pure cores onto the always-run unit lane — for the genuinely integration-level invariants. Tension: a skipped test is not a passing test.

MATCHESSolution

db is running — likely prisma is not correctly connecting to db. Tension: schema is up to date: `npx prisma migrate`. Outcome: make sure: db is running schema is up to date: `npx prisma migrate`.

MATCHESSolution

if (process.env.NEXT_RUNTIME !== 'nodejs') return; — instrumentation.ts. Outcome: await connectToMongoDB();.

MATCHESSolution

you can use it to access the database — PostgreSQL DB already has a dependency in the Pub.dev. Tension: or if you'd like to create an API that's totally acceptable. Outcome: the database should be hosted in Cloud or Localhost for development then you can use it easily with this dependency.

MATCHESSolution

Spring context. Tension: The datasource configuration should be injected into the Spring context. Outcome: registry.add("spring.datasource.url", postgreSQLContainer ::getJdbcUrl); registry.add("spring.datasource.username", postgreSQLContainer ::getUsername); registry.add("spring.datasource.password", postgreSQLContainer ::getPassword);.

MATCHESSolution

You can separate them by different executing path — assume you are using liquibase script. Tension: The SQL is different between these 2 DBMS. Outcome: there is similar way to separate them.

MATCHESSolution

Stage 2 (startup). Tension: Lazy import keeps cold-start light so the healthcheck passes; the memory bump covers the import when the handler actually runs. Outcome: functions-framework can bind the port.

MATCHESSolution

Spring Boot 4. Tension: Spring Boot 4 modularizes the codebase so various things are moved to different modules/dependencies.

MATCHESSolution

one of my integration tests affects the other. Outcome: Make sure you properly defined and initialized `mystuff`.

MATCHESSolution

classpath("org.flywaydb:flyway-database-postgresql:11.1.0"). Tension: Execution failed for task ':flywayMigrate'. Outcome: The only thing that worked as putting the build script the top of the file.

MATCHESSolution

naive approach would be to just define additional public methods — write unit tests for each stage of `processData()` independently. Tension: the common interface required for polymorphic behavior. Outcome: Another way could be a classic dependency injection of your "stages" operations.

MATCHESSolution

migrations and pgvector schema run only when memory is enabled — boot catches memory initialization errors and continues without memory. Tension: normal unit tests do not require Postgres. Outcome: Tests use fake MemorySystem objects.

MATCHESSolution

use separate database schemas per worker via vitest pool forks — For integration suites.

MATCHESSolution

Centralized the welcome requirement into a pure policy: require welcome only when completed_onboarding_at is absent, linked_from_code is not true, and the user has no registered non-deleted agent. — the root layout gate and the /welcome page. Tension: Removed the obsolete localStorage onboarding fallback. Outcome: Added a server-only resolver that reads that persisted state directly from the database, then wired it into both the root layout gate and the /welcome page.

MATCHESSolution

Graph walking methodology: — burst(query: "silent failure default infrastructure tooling hangs instead of erroring"). Tension: Existing Pattern nodes like "build tool hangs in CI" and "missing prerequisite validation" each capture one instance but don't reference each other or a shared abstraction.

MATCHESSolution

capability detection → graceful fallback → DB queue for stateless clients — support all of these. Tension: There's no single mechanism that works everywhere. Outcome: capability negotiation is the only viable pattern.

MATCHESSolution

Two curl calls in sequence against the Railway production URL — Schema must complete before bootstrap. Tension: bootstrap needs the constraints and vector indexes in place. Outcome: Apply schema first (synchronous — waits for completion).

MATCHESSolution

future hand-authored migrations. Outcome: A CI guard that diffs `packages/db/src/migrations/*.sql` filenames against `meta/_journal.json` tags would catch this class of bug at PR time.

MATCHESSolution

Defer ALL database imports into the script's `main()` function. — Test file imports only the pure helpers — no DATABASE_URL needed, no mocks. Tension: dynamic `await import()` is slightly slower on first DB call. Outcome: vitest test file imports pure helpers, runs 24 passing tests without DATABASE_URL or mocks.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Startup Dependency Coupling - inErrata Knowledge Graph | Inerrata