Hidden Assumptions in lightdash
13 assumptions this code never checks · 5 critical · spanning Resource, Environment, Contract, Scale, Ordering, Domain, Temporal, Shape
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at lightdash/lightdash and picked out the few most likely to cause trouble. The full list is just below.
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If a server returns a malformed Set-Cookie header or cookie values with embedded semicolons/equals, the cookie parsing silently fails or stores corrupted values, breaking session management
All API tests fail with connection errors if the target service is down or the URL is wrong, with no retry logic or health checks
If session data is corrupted or the user is deleted between login and subsequent requests, authentication silently fails or returns undefined user context
Show everything (10 more)
The maximum_bytes_billed setting in dbt profiles is sufficient to prevent runaway BigQuery costs, with no runtime validation that query costs stay within this limit
If this fails: Users can accidentally trigger expensive BigQuery queries that exceed their intended budget if the dbt profile setting is misconfigured or missing
packages/cli/src/dbt/targets/Bigquery/index.ts:maximum_bytes_billed
Project profiles array contains all current project memberships for the user in consistent order, with no duplicate projectUuid entries that could cause permission conflicts
If this fails: If projectProfiles has duplicates or stale data, the last processed role for each project wins, potentially granting wrong permissions or access to deleted projects
packages/common/src/authorization/index.ts:getUserAbilityBuilder
The CompileOptions.dialect field always maps to exactly one of the hardcoded warehouse types (postgres, bigquery, snowflake, duckdb), with no support for dialect versioning or custom warehouse types
If this fails: Adding new warehouse support or handling dialect variations requires code changes; unknown dialects throw runtime errors instead of falling back gracefully
packages/formula/src/codegen/index.ts:createGenerator
All required environment variables for each warehouse type (like FORMULA_TEST_BQ_PROJECT, FORMULA_TEST_SF_ACCOUNT) are set when those warehouses are included in test runs
If this fails: Tests fail with cryptic connection errors if warehouse-specific environment variables are missing, with no clear indication of which variables need to be set
packages/formula-tests/config.ts:getWarehouseConfig
The React Query cache invalidation for 'projectCompileLogs' happens atomically and the fresh data will be immediately available for re-rendering
If this fails: If the cache invalidation fails or the backend is slow to respond, users see stale compilation data even after clicking refresh, with success toast shown prematurely
packages/frontend/src/components/CompilationHistory/index.tsx:handleRefresh
The mapCronExpressionToFrequency function can always parse any cron expression string passed as the 'value' prop, even malformed or custom expressions
If this fails: Invalid cron expressions cause the frequency selector to show incorrect state or crash the component, breaking the scheduling UI
packages/frontend/src/components/CronInput/index.tsx:useEffect
The fetch() call will complete within reasonable time limits and network errors are properly handled by the underlying fetch implementation
If this fails: Long-running queries or network issues cause tests to hang indefinitely since there's no explicit timeout configuration
packages/api-tests/helpers/api-client.ts:request
All Lightdash API responses follow the exact shape { status: string, results: T } but only enforces this through TypeScript typing, not runtime validation
If this fails: If the backend returns differently structured responses, TypeScript compilation succeeds but runtime access to response.body.results fails with undefined errors
packages/api-tests/helpers/api-client.ts:Body<T>
The tier system (fast/tier1/tier2/all) represents increasing complexity and execution time, with DuckDB always being fastest and BigQuery/Snowflake being slowest
If this fails: If warehouse performance characteristics change or new warehouses are added with different performance profiles, the tier classifications become misleading
packages/formula-tests/config.ts:TIER_WAREHOUSES
The customRoleScopes record contains scopes for every roleUuid referenced in projectProfiles when customRolesEnabled is true, with no missing or orphaned role definitions
If this fails: Missing custom role definitions log console errors and skip permission grants, potentially leaving users with no project access despite having role assignments
packages/common/src/authorization/index.ts:customRoleScopes
See the full structural analysis of lightdash: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of lightdash/lightdash →Frequently Asked Questions
What does lightdash assume that could break in production?
The one most likely to cause trouble: The Set-Cookie headers from the response will always be parseable with the split(';') and indexOf('=') pattern, assuming cookie values never contain semicolons or equals signs in their base form If this fails, If a server returns a malformed Set-Cookie header or cookie values with embedded semicolons/equals, the cookie parsing silently fails or stores corrupted values, breaking session management
How many hidden assumptions does lightdash have?
CodeSea found 13 assumptions lightdash relies on but never validates, 5 of them critical, spanning Resource, Environment, Contract, Scale, Ordering, Domain, Temporal, Shape. Most are routine — the analysis flags the two or three most likely to actually bite.
What is a hidden assumption?
Something the code depends on but never checks: a data shape, an ordering, an environment condition, a scale limit, or a contract with another service. It holds until the world it runs in changes, then fails silently.