Hidden Assumptions in graphql
13 assumptions this code never checks · 4 critical · spanning Environment, Shape, Domain, Contract, Ordering, Scale, Temporal, Resource
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at redwoodjs/graphql 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".
CLI crashes with 'no such file or directory' error when user specifies a directory that doesn't contain a redwood.toml file, providing no guidance on what went wrong
Server startup fails with cryptic import errors if server.config.js has syntax errors, missing exports, or uses CommonJS instead of ES modules, with no validation of the structure
isFullyQualifiedUrl() function receives invalid input causing URL validation logic to fail silently or throw runtime errors during proxy setup
Show everything (10 more)
Assumes Authorization header splits into exactly 2 parts on space character and both parts have non-zero length
If this fails: Function throws generic 'not valid' error for headers like 'Bearer token extra' or 'Bearer' without token, making debugging auth issues harder
packages/api/src/auth/index.ts:parseAuthorizationHeader
Assumes getAsyncStoreInstance() always returns a valid AsyncLocalStorage instance that supports the run() method
If this fails: Server crashes during request handling if context initialization fails, breaking all request isolation and potentially corrupting global state
packages/api-server/src/fastify.ts:createFastifyInstance
Assumes server configuration loading happens before any request processing and uses module-level caching via isServerConfigLoaded flag
If this fails: Race condition during concurrent server startup could result in loading config multiple times or serving requests with incomplete configuration
packages/api-server/src/fastify.ts:loadFastifyConfig
Assumes prettier.config.js exists at project root and exports a default object, with optional tailwindConfig property being a string
If this fails: Template generation silently continues without formatting if prettier config is malformed, corrupted, or uses named exports instead of default, resulting in inconsistent code style
packages/cli-helpers/src/lib/index.ts:getPrettierOptions
Assumes babel.transform() can handle any TypeScript file size and complexity in memory during CLI operations
If this fails: Process runs out of memory or hangs when transforming very large generated files, especially in monorepos with complex TypeScript configurations
packages/cli-helpers/src/lib/index.ts:transformTSToJS
Assumes process.env.NODE_ENV controls babel configuration discovery, with 'test' bypassing getPaths().base cwd setting
If this fails: Babel loads wrong configuration during test runs if NODE_ENV is not exactly 'test', causing template generation to fail with different syntax rules
packages/cli-helpers/src/lib/index.ts:transformTSToJS
Assumes input logData has numeric level property (10,20,30,40,50,60) mapping to standard log levels, but only checks logData.level existence
If this fails: Log formatter breaks or produces garbled output when receiving custom log levels, non-numeric levels, or levels outside the expected range
packages/api-server/src/logFormatter/index.ts:LogFormatter
Assumes server.config.js file contents remain stable after initial import and caching, with no file watching or cache invalidation
If this fails: Server configuration changes during development require full restart since cached config never updates, making hot-reload development workflows frustrating
packages/api-server/src/fastify.ts:loadFastifyConfig
Assumes AUTH_PROVIDER_HEADER constant value matches cookie names used by authentication providers, with no runtime validation
If this fails: Cookie-based authentication silently fails if auth providers use different header names or the constant gets out of sync, returning null without error indication
packages/api/src/auth/index.ts:parseAuthorizationCookie
Assumes tempy.directory() creates writable temporary directories and system has permissions to create files there
If this fails: Test setup fails in restricted environments, CI systems, or when disk space is low, causing test suite to crash rather than skip gracefully
packages/codemods/src/testUtils/index.ts:createProjectMock
See the full structural analysis of graphql: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of redwoodjs/graphql →Frequently Asked Questions
What does graphql assume that could break in production?
The one most likely to cause trouble: Assumes redwood.toml exists at path.join(cwd, 'redwood.toml') when cwd is set via --cwd or RWJS_CWD environment variable If this fails, CLI crashes with 'no such file or directory' error when user specifies a directory that doesn't contain a redwood.toml file, providing no guidance on what went wrong
How many hidden assumptions does graphql have?
CodeSea found 13 assumptions graphql relies on but never validates, 4 of them critical, spanning Environment, Shape, Domain, Contract, Ordering, Scale, 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.