Hidden Assumptions in netdata
12 assumptions this code never checks · 6 critical · spanning Environment, Scale, Domain, Ordering, Resource, Contract, Temporal
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at netdata/netdata 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 machine-id contains non-hex characters, has wrong length, or is missing, journal files cannot be created/opened - causing complete monitoring system failure with cryptic 'UuidSerde' errors that don't indicate the root cause
In container environments without proper volume mounts or with restricted permissions, the fallback to /host/etc/machine-id fails silently or with permission errors, leaving no way to access the machine ID
If called from C code with non-null-terminated strings or freed memory, the CStr::from_ptr() call reads past allocated memory, potentially causing segfaults or reading garbage data into the ID structure
Show everything (9 more)
System page size is always exactly 4096 bytes across all target platforms and architectures
If this fails: On systems with different page sizes (like some ARM64 with 64KB pages), memory mappings will be misaligned, causing performance degradation or mapping failures when the OS requires page-aligned offsets
src/crates/jf/window_manager/src/lib.rs:PAGE_SIZE
GUID format dashes appear at exactly positions 8, 13, 18, and 23, and non-GUID format contains no dashes at all
If this fails: Malformed UUIDs with dashes in wrong positions return -1 error code, but the calling C code may not handle this gracefully, potentially using uninitialized RsdId128 data in subsequent operations
src/crates/jf/journal_reader_ffi/src/lib.rs:rsd_id128_from_string
The filesystem has sufficient space and the process has permission to extend files via set_len() when mapping regions beyond current file size
If this fails: When journal files need to grow but disk is full or filesystem is read-only, set_len() fails and the entire memory mapping operation aborts, stopping metric collection with no graceful degradation
src/crates/jf/window_manager/src/lib.rs:MemoryMapMut::create
Memory mapping offsets and sizes fit within usize limits on the target platform (offset: u64 cast to usize for len parameter)
If this fails: On 32-bit systems or when mapping very large journal files (>4GB), the size cast from u64 to usize silently truncates, creating mappings smaller than requested and causing out-of-bounds access when reading data
src/crates/jf/window_manager/src/lib.rs:MmapOptions
Callers always validate position and size parameters against window bounds before calling get_slice() - the debug_assert provides no protection in release builds
If this fails: In production builds, invalid position/size parameters cause get_slice to return memory outside the mapped region, leading to potential segfaults or reading garbage data without any error indication
src/crates/jf/window_manager/src/lib.rs:Window::get_slice
The window's memory mapping remains valid and hasn't been unmapped by another thread between the bounds check and actual memory access
If this fails: In multi-threaded scenarios, a window could be unmapped after contains_range() returns true but before get_slice() accesses the memory, resulting in segfaults from accessing unmapped memory
src/crates/jf/window_manager/src/lib.rs:Window::contains_range
Input bytes represent ASCII characters in the range 0-127, not UTF-8 multibyte sequences
If this fails: When processing UTF-8 strings containing non-ASCII characters that happen to have byte values in hex ranges, unhexchar processes individual bytes rather than characters, producing incorrect hex decoding results
src/crates/jf/journal_reader_ffi/src/lib.rs:unhexchar
The target_os configuration correctly identifies Linux systems, and non-Linux systems don't call this function
If this fails: If compiled for Linux but running on a different OS, or if the cfg attribute fails to properly exclude the function, attempts to read /etc/machine-id will fail on systems that don't have this file
src/crates/jf/journal_file/src/file.rs:load_machine_id
The File reference remains valid and the underlying file descriptor hasn't been closed during the memory mapping operation
If this fails: If the file is closed by another thread or process during mapping, the unsafe mmap operations may succeed but create invalid mappings, leading to segfaults or data corruption when accessing the mapped memory
src/crates/jf/window_manager/src/lib.rs:unsafe MmapOptions
See the full structural analysis of netdata: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of netdata/netdata →Frequently Asked Questions
What does netdata assume that could break in production?
The one most likely to cause trouble: The /etc/machine-id file exists on every Linux system and contains exactly 32 hexadecimal characters (16 bytes when decoded) with no extra whitespace beyond what trim() can handle If this fails, If machine-id contains non-hex characters, has wrong length, or is missing, journal files cannot be created/opened - causing complete monitoring system failure with cryptic 'UuidSerde' errors that don't indicate the root cause
How many hidden assumptions does netdata have?
CodeSea found 12 assumptions netdata relies on but never validates, 6 of them critical, spanning Environment, Scale, Domain, Ordering, Resource, Contract, Temporal. 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.