Hidden Assumptions in umami
13 assumptions this code never checks · 5 critical · spanning Contract, Shape, Ordering, Environment, Scale, Domain, Temporal, Resource
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at umami-software/umami 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 database constraints fail or data is malformed, some records silently fail to insert but the script continues, leading to incomplete seed data with no error indication
If a website component expects different props than a pixel component for the same board type, runtime errors occur when wrong component receives incompatible props
If DATABASE_URL points to ClickHouse or another database type, PrismaPg adapter fails with cryptic connection errors instead of clear configuration guidance
Show everything (10 more)
Assumes PIXEL_LINK_METRIC_TYPES filtering removes items that don't apply to pixels/links, but the filter logic only checks against a hardcoded subset - if METRIC_TYPES gains new items, they're included by default
If this fails: New metric types added to METRIC_TYPES automatically become available for pixel/link components even if those entity types don't support them, causing query failures or empty results
src/app/(main)/boards/boardComponentRegistry.tsx:METRIC_TYPES
Assumes BATCH_SIZE of 1000 records fits within database connection limits and memory constraints for all deployment environments
If this fails: On resource-constrained servers or databases with low connection limits, batch inserts fail with out-of-memory errors or connection timeouts
scripts/seed/index.ts:BATCH_SIZE
Assumes all exported hook modules follow the same naming convention and export structure - exports everything with * but doesn't validate individual module exports
If this fails: If a query hook module exports non-hook functions or uses different naming patterns, they become part of the public API unintentionally, breaking consumer expectations
src/components/hooks/index.ts:export
Assumes components marked with requiresWebsite: true will only be used in website contexts, but provides no runtime validation that websiteId is available in component props
If this fails: Website-dependent components render in non-website boards (like pixel dashboards) and fail silently or crash when trying to access undefined website data
src/app/(main)/boards/boardComponentRegistry.tsx:requiresWebsite
Assumes generated seed data dates align with current system timezone and don't cross daylight saving time boundaries that could affect analytics aggregations
If this fails: Seed data spans DST transitions causing hour gaps/duplicates in time-series charts, making dashboard testing unrealistic compared to production data patterns
scripts/seed/index.ts:generateDatesBetween
Assumes optionsByEntityType keys match valid entity type strings ('website', 'pixel', 'link') but doesn't validate against an enumeration or type definition
If this fails: Typos in entity type keys cause config fields to disappear silently - users can't configure components properly and receive no error feedback
src/app/(main)/boards/boardComponentRegistry.tsx:ConfigField.optionsByEntityType
Assumes console output is available and supports progress bar formatting - doesn't handle environments where stdout is redirected or progress updates cause issues
If this fails: In Docker containers, CI environments, or log aggregation systems, progress bar output clutters logs with ANSI escape codes instead of clean progress indication
scripts/seed/index.ts:progressBar
Assumes all SVG components export a React component as default export and follow consistent naming - doesn't validate component interface compatibility
If this fails: If an SVG file exports a different structure or requires props, TypeScript compilation succeeds but runtime fails when components expect standard icon props
src/components/svg/index.ts:export
Assumes metric type values match exactly the field names in the database schema and API responses - hardcoded strings with no validation against actual data model
If this fails: If database schema changes field names (e.g., 'utmSource' becomes 'utm_source'), metric tables show empty results but provide no indication that the field mapping is broken
src/app/(main)/boards/boardComponentRegistry.tsx:METRIC_TYPES.value
Assumes seed data generation can handle any number of days without memory overflow - multiplies sessions per day by number of days without checking total record count limits
If this fails: Seeding 365 days of high-traffic site data could generate millions of records, exhausting available memory or database storage without warning
scripts/seed/index.ts:SeedConfig.days
See the full structural analysis of umami: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of umami-software/umami →Frequently Asked Questions
What does umami assume that could break in production?
The one most likely to cause trouble: Assumes createMany operation succeeds silently even with invalid data - uses skipDuplicates: true but doesn't validate that inserted record count matches expected count If this fails, If database constraints fail or data is malformed, some records silently fail to insert but the script continues, leading to incomplete seed data with no error indication
How many hidden assumptions does umami have?
CodeSea found 13 assumptions umami relies on but never validates, 5 of them critical, spanning Contract, Shape, Ordering, Environment, Scale, Domain, Temporal, Resource. 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.