Hidden Assumptions in onnxruntime
10 assumptions this code never checks · 4 critical · spanning Ordering, Environment, Contract, Temporal, Scale, Domain
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at microsoft/onnxruntime 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 multiple backends support the same operations and are registered with equal or higher priorities, the Node.js backend may be bypassed, causing fallback to less optimal execution paths without warning
If these constants are undefined or have inconsistent values between modules, backends may be double-registered, missing, or throw configuration errors at runtime rather than build time
If bundlers or runtime environments don't properly handle conditional requires, or if the required modules don't export the expected objects, the application fails at runtime with cryptic module loading errors
Show everything (7 more)
The listSupportedBackends() function always returns an array of objects with a 'name' property that matches valid backend names expected by registerBackend()
If this fails: If listSupportedBackends() returns malformed objects, null values, or backend names that don't correspond to actual implementations, the registration loop silently registers invalid backends or crashes with property access errors
js/node/lib/index.ts:listSupportedBackends
Build configuration errors (JSEP + WebGPU enabled together, WebNN without JSEP/WebGPU) are the only invalid combinations that need to be checked
If this fails: Other invalid build configurations may pass validation but result in runtime failures or degraded performance when actual inference is attempted, with no clear indication of the root cause
js/web/lib/index.ts:configuration validation
Backend registration happens before any inference sessions are created, and the registerBackend() calls complete synchronously
If this fails: If inference sessions are created before all backends are registered (in async scenarios), they may fall back to suboptimal backends or fail to find required execution providers
js/react_native/lib/index.ts:backend registration timing
Backend priority values (-10 for webgl, 5 for webgpu/webnn, 10 for cpu/wasm) create the intended execution order and won't conflict with priorities set by user code
If this fails: If user code registers backends with intermediate priority values, or if the priority scale doesn't provide enough granularity, backends may execute in unexpected order leading to suboptimal performance
js/web/lib/index.ts:backend priority values
The env.versions object exists and can be safely extended with version information using Object.defineProperty
If this fails: If env.versions is frozen, sealed, or undefined, version injection fails silently or throws errors, potentially breaking version detection in downstream code
js/node/lib/index.ts:version object
The 'onnxruntime-common' module exports all necessary types and interfaces as named exports that can be safely re-exported
If this fails: If 'onnxruntime-common' has breaking changes in its export structure, the re-export statements fail and applications importing from this module lose access to core functionality
js/web/lib/index.ts:default export
React Native backends should have the lowest priority (1) among all platform-specific backends to act as fallbacks
If this fails: If this priority assumption is wrong and React Native backends should be preferred, optimal execution providers won't be selected on React Native platforms
js/react_native/lib/index.ts:backend priority 1
See the full structural analysis of onnxruntime: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of microsoft/onnxruntime →Frequently Asked Questions
What does onnxruntime assume that could break in production?
The one most likely to cause trouble: Backend registration order determines execution priority, with the Node.js backend always registered at priority 100 for all discovered backends If this fails, If multiple backends support the same operations and are registered with equal or higher priorities, the Node.js backend may be bypassed, causing fallback to less optimal execution paths without warning
How many hidden assumptions does onnxruntime have?
CodeSea found 10 assumptions onnxruntime relies on but never validates, 4 of them critical, spanning Ordering, Environment, Contract, Temporal, Scale, Domain. 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.