Hidden Assumptions in graphql-engine
13 assumptions this code never checks · 4 critical · spanning Contract, Environment, Domain, Shape, Resource, Temporal, Scale, Ordering
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at hasura/graphql-engine 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 the header contains malformed JSON, missing 'db' property, or points to a non-existent/inaccessible file, the SQLite connector will fail to initialize but the error won't indicate which specific validation failed
If database file doesn't exist or has wrong permissions, the SQLite.Database constructor will callback with an error, but the error handling doesn't distinguish between file not found vs permission denied vs corrupted database
If XML files use different encoding (UTF-8, UTF-32) or different root element naming convention, xml2js parsing will fail with cryptic encoding errors or the data extraction will return undefined
Show everything (10 more)
SchemaResponse.tables array contains ColumnInfo objects with 'type' property set to exactly 'number' for numeric columns, and XML data contains numeric values in columns marked as type 'number'
If this fails: If schema uses different type names ('integer', 'float', 'numeric') or XML contains non-numeric values in numeric columns, the selective number parsing will either parse strings as numbers incorrectly or leave valid numbers as strings
dc-agents/reference/src/data/index.ts:parseNumbersInNumericColumns
DB_ALLOW_LIST environment variable, if set, contains database paths that should be blocked (inverse logic), and database connections can be opened synchronously without connection pool limits
If this fails: The allow list logic is inverted - it blocks databases IN the allow list rather than allowing only those databases. Also, no connection pooling means concurrent requests can exhaust file descriptors
dc-agents/sqlite/src/db.ts:withConnection
Schema JSON files and compressed XML data files are synchronized - if one exists, the matching file should also exist and be from the same dataset version
If this fails: Function only checks file accessibility, not content consistency. If schema.json is updated but xml.gz is stale, loadStaticData will succeed but return mismatched schema/data causing silent data corruption
dc-agents/reference/src/data/index.ts:staticDataExists
Compressed XML files are small enough to be fully loaded into memory as a single buffer without memory constraints or timeouts
If this fails: Large XML datasets (>1GB compressed) will cause out-of-memory errors or hang the process without timeout, affecting all other requests to the data connector
dc-agents/reference/src/data/index.ts:streamToBuffer
KeyValuePair arrays contain unique keys - if duplicate keys exist, later values should overwrite earlier ones silently
If this fails: Function uses object spread to merge pairs, so duplicate keys get overwritten without warning. Configuration UI may show multiple entries for same key but only last value is used, confusing users
frontend/libs/console/legacy-ce/src/lib/components/Common/ConfigureTransformation/utils.ts:getPairsObjFromArray
Session variables in GraphQL headers must have names starting with 'x-hasura' (case insensitive) to be valid session variables
If this fails: Headers like 'X-Custom-Auth' or 'authorization' won't be recognized as session variables, potentially causing permission checks to fail silently when custom auth headers are expected
frontend/libs/console/legacy-ce/src/lib/components/Common/ConfigureTransformation/utils.ts:getSessionVarsArrayFromGraphiQL
SQLite transaction operations (BEGIN, COMMIT, ROLLBACK) execute synchronously and in order without other operations interleaving
If this fails: If concurrent queries execute between BEGIN and COMMIT, they might see partial transaction state. No transaction isolation level is specified, defaulting to SQLite's default which may not match application expectations
dc-agents/sqlite/src/db.ts:withTransaction
Environment variables DB_READONLY, DB_CREATE, and DB_PRIVATECACHE are boolean-interpretable values that remain constant during process lifetime
If this fails: If environment variables change during runtime or contain non-boolean values, the defaultMode flags are calculated once at module load and won't reflect new values, potentially opening read-only databases in write mode or vice versa
dc-agents/sqlite/src/db.ts:defaultMode
JSON.parse() on the config header will succeed and produce an object with optional boolean/string/array properties that match the expected schema
If this fails: If config contains unexpected types (numbers for booleans, objects for strings), the type coercion (config.explicit_main_schema ?? false) may produce wrong types, causing SQLite operations to fail with type errors later
dc-agents/sqlite/src/config.ts:tryGetConfig
Config.tables array, if provided, contains valid table names that exist in the loaded StaticData.schema.tables array
If this fails: If config specifies non-existent table names, the filtering will silently exclude them from available tables without error, making it unclear whether tables are missing from config or from data source
dc-agents/reference/src/data/index.ts:filterAvailableTables
See the full structural analysis of graphql-engine: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of hasura/graphql-engine →Frequently Asked Questions
What does graphql-engine assume that could break in production?
The one most likely to cause trouble: The X-Hasura-DataConnector-Config header contains valid JSON with a 'db' property that is a string path to an accessible SQLite database file If this fails, If the header contains malformed JSON, missing 'db' property, or points to a non-existent/inaccessible file, the SQLite connector will fail to initialize but the error won't indicate which specific validation failed
How many hidden assumptions does graphql-engine have?
CodeSea found 13 assumptions graphql-engine relies on but never validates, 4 of them critical, spanning Contract, Environment, Domain, Shape, Resource, Temporal, Scale, Ordering. 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.