Hidden Assumptions in wasp
10 assumptions this code never checks · 4 critical · spanning Shape, Domain, Temporal, Environment, Resource, Contract, Ordering, Scale
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at wasp-lang/wasp 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 tarball target contains unexpected fields or missing os/arch fields, makeSubPackageName could crash with property access errors or generate invalid package names
If database setup returns malformed results or null/undefined dbEnvVars, the subsequent waspMigrateDb and waspStart calls will fail with cryptic environment variable errors
If migrations fail silently or partially complete, the app server starts with an inconsistent database schema, leading to runtime errors when operations try to access missing tables or columns
Show everything (7 more)
CSS custom property names generated from Object.entries(tokenObj) will always produce valid CSS variable names, but doesn't validate that keys don't contain spaces, special characters, or start with numbers
If this fails: Invalid CSS variable names like '--prefix-123invalid' or '--prefix-my key' get injected into styles, causing CSS parsing errors and broken styling without obvious error messages
waspc/data/Generator/templates/sdk/wasp/auth/forms/internal/util.ts:tokenObjToCSSVars
The data.json file at the specified input path will always be valid JSON and not exceed memory limits when loaded synchronously
If this fails: Large build data files (>1GB) cause out-of-memory crashes, while malformed JSON files throw parse errors that don't indicate which specific field or line is invalid
scripts/make-npm-packages/src/index.ts:fs.readJsonSync
The context.user property is either a valid AuthUser object or null/undefined, but doesn't validate that user object has required fields like id or email before passing to authenticated operations
If this fails: If authentication middleware provides a malformed user object missing critical fields, authenticated operations receive incomplete user data and may fail with property access errors or security bypasses
examples/kitchen-sink/src/rpcTests/operations/server.ts:testingAction
TypeScript setup (waspTsSetup) must complete before starting the app in any mode, but there's no validation that the setup actually succeeded or that generated TypeScript files are valid
If this fails: If TypeScript setup fails or generates broken type definitions, the subsequent development or build process starts with invalid TypeScript configuration, leading to cryptic compilation errors that don't point to the root cause
wasp-app-runner/src/index.ts:runWaspApp
The number of tarballs in BuildData will be reasonable (probably <100) for synchronous processing, but doesn't handle scenarios with thousands of platform-specific builds
If this fails: With hundreds of platform targets, the synchronous package creation process blocks for minutes without progress feedback and may hit filesystem limits for concurrent directory operations
scripts/make-npm-packages/src/index.ts:data.tarballs.map
The isWaspTypescriptConfigProject function can reliably detect TypeScript projects by reading directory contents, but doesn't account for symbolic links, permission issues, or network mounted filesystems
If this fails: On systems with restricted file permissions or when the project directory is a symlink, TypeScript detection fails silently and setup is skipped, causing subsequent compilation errors that appear unrelated to TypeScript configuration
wasp-app-runner/src/index.ts:isWaspTypescriptConfigProject
Session IDs will always be non-empty strings, but the z.string() validator allows empty strings which could represent invalid sessions
If this fails: Empty session IDs pass validation and get treated as valid sessions throughout the auth system, potentially allowing unauthorized access or causing session management to fail unpredictably
waspc/data/Generator/templates/sdk/wasp/auth/responseSchemas.ts:SessionResponseSchema
See the full structural analysis of wasp: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of wasp-lang/wasp →Frequently Asked Questions
What does wasp assume that could break in production?
The one most likely to cause trouble: The makeSubPackageName function expects target object to have specific properties (os, arch) but the code only validates it against BuildDataSchema which allows any properties If this fails, If a tarball target contains unexpected fields or missing os/arch fields, makeSubPackageName could crash with property access errors or generate invalid package names
How many hidden assumptions does wasp have?
CodeSea found 10 assumptions wasp relies on but never validates, 4 of them critical, spanning Shape, Domain, Temporal, Environment, Resource, Contract, Ordering, Scale. 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.