Hidden Assumptions in kong
15 assumptions this code never checks · 3 critical · spanning Environment, Temporal, Resource, Shape, Contract, Ordering, Domain, Scale
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at kong/kong 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 Docker is not installed or daemon is not running, the gather_files() function will silently fail with os.system() returning non-zero, but the error message 'Failed to extract image %s' doesn't indicate Docker availability issues
If Kong PDK changes its API structure or the kong.kong object is malformed, accessing kong.request.get_header or kong.response.set_header will raise AttributeError, causing the plugin to crash without graceful error handling
If the function is invoked outside of API Gateway context or with a different event format, accessing expected event properties will raise KeyError, but the function doesn't validate event structure before processing
Show everything (12 more)
Docker container name generated from time.time() will be unique across concurrent executions
If this fails: If two processes run explain_manifest simultaneously, they generate containers named 'explain_manifest_<timestamp>' that could collide if time.time() returns identical values, causing docker create to fail
scripts/explain_manifest/main.py:gather_files
Global caches dict can grow indefinitely without memory constraints during binary analysis
If this fails: When analyzing large numbers of ELF files, the caches dict accumulates parsed metadata without any eviction policy, potentially causing out-of-memory errors on systems with limited RAM
scripts/explain_manifest/explain.py:caches
kong.Request.GetHeader('host') returns a non-empty string when successful
If this fails: If the Host header is present but empty, the plugin sets response header 'x-hello-from-go' to 'Go says <message> to ' with trailing space, and stores empty string in shared context, which may confuse downstream plugins expecting meaningful host values
spec/fixtures/external_plugins/go/go-hello.go:Access
this.config is a plain object where this.config.message can be safely accessed
If this fails: If the plugin configuration is null, undefined, or not an object, accessing this.config.message will not throw but may return undefined, leading to 'Javascript says undefined to <host>' in the response header
spec/fixtures/external_plugins/js/js-hello.js:access
Promise.all() executes setHeader calls in the order they can complete, not necessarily array order
If this fails: If one setHeader call fails while the other succeeds, only partial headers are set with no indication which one failed, potentially leaving the response in an inconsistent state for debugging
spec/fixtures/external_plugins/js/js-hello.js:access
get_plugin_configuration() returns valid UTF-8 bytes that can be parsed as JSON matching the Config struct
If this fails: If the configuration contains invalid UTF-8 or malformed JSON, serde_json::from_slice will fail and the filter returns false, but the error message only shows parsing failure without indicating whether it was UTF-8 or JSON structure issue
spec/fixtures/proxy_wasm_filters/response_transformer/src/filter.rs:on_configure
Thread-local METRICS HashMap can store metric IDs indefinitely without cleanup
If this fails: In long-running proxy processes, the metrics HashMap accumulates entries for every unique metric name ever defined, potentially consuming unbounded memory if metric names are dynamically generated or contain unique identifiers
spec/fixtures/proxy_wasm_filters/tests/src/metrics.rs:get_metric_id
FileInfo object f has rpath and runpath attributes that are either None or strings containing colon-separated paths
If this fails: If ELF parsing produces rpath/runpath as unexpected types (lists, bytes, etc.), the 'expected_rpath in f.rpath' check will raise TypeError instead of gracefully handling malformed binary metadata
scripts/explain_manifest/config.py:transform
Command line argument processing handles reasonable numbers of glob patterns and file paths
If this fails: If --file_list points to a file with thousands of glob patterns, the read_glob() function loads them all into memory at once without pagination, potentially causing memory issues with very large file lists
scripts/explain_manifest/main.py:parse_args
TemporaryDirectory cleanup via atexit.register() will execute before process termination
If this fails: If the process is killed with SIGKILL or crashes unexpectedly, the temporary directory containing extracted Docker image data will not be cleaned up, potentially filling up disk space over time
scripts/explain_manifest/main.py:gather_files
kong.Nginx.GetCtxFloat('KONG_ACCESS_START') returns a valid timing measurement from Kong's request processing
If this fails: If Kong's internal timing context is not set or contains non-numeric data, GetCtxFloat will error but the error handling is incomplete (code is cut off), potentially causing the Log phase to fail silently
spec/fixtures/external_plugins/go/go-hello.go:Log
os.getpid() returns a meaningful process identifier that can be converted to string
If this fails: While os.getpid() should always work on POSIX systems, in containerized environments or process namespaces, the PID may not be meaningful for debugging, leading to confusing 'x-python-pid' header values
spec/fixtures/external_plugins/py/py-hello.py:access
See the full structural analysis of kong: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of kong/kong →Frequently Asked Questions
What does kong assume that could break in production?
The one most likely to cause trouble: Docker commands (docker pull, docker create, docker export, docker rm) are available in PATH and Docker daemon is running If this fails, If Docker is not installed or daemon is not running, the gather_files() function will silently fail with os.system() returning non-zero, but the error message 'Failed to extract image %s' doesn't indicate Docker availability issues
How many hidden assumptions does kong have?
CodeSea found 15 assumptions kong relies on but never validates, 3 of them critical, spanning Environment, Temporal, Resource, Shape, Contract, Ordering, Domain, 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.