Hidden Assumptions in mlc-llm
10 assumptions this code never checks · 4 critical · spanning Domain, Resource, Contract, Environment, Scale, Temporal, Ordering
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at mlc-ai/mlc-llm 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 URI points to corrupted file, network location, or non-image content, BitmapFactory.decodeStream() returns null causing NullPointerException when converting to base64 string
if external storage is unavailable, full, or model directory missing, MLCEngine initialization fails with cryptic native library errors instead of clear file not found errors
large images (>50MB uncompressed) cause OutOfMemoryError during bitmap.compress() or Base64.encode(), crashing the chat session
Show everything (7 more)
assumes adb is installed, in PATH, device is connected via USB with debugging enabled, and device has sufficient storage space at /data/local/tmp/
If this fails: script fails silently or with cryptic errors if adb not found, device disconnected, or device storage full during weight file push
android/MLCChat/bundle_weight.py:adb commands
assumes the hardcoded model library name 'phi_msft_q4f16_1_686d8979c6ebf05d142d9081f1b87162' exactly matches the compiled .so file name in the app bundle
If this fails: if model is recompiled with different hash or quantization settings, native library loading fails with UnsatisfiedLinkError but no indication of name mismatch
android/MLCEngineExample/app/src/main/java/ai/mlc/mlcengineexample/MainActivity.kt:modelLib hardcoded string
assumes image URIs returned by ActivityResultContracts.GetContent() remain valid and accessible for the lifetime of the chat session
If this fails: if user deletes image file or URI permissions are revoked after selection, subsequent access for message display or model input fails with SecurityException
android/MLCChat/app/src/main/java/ai/mlc/mlcchat/MainActivity.kt:pickImageLauncher
assumes coroutine operations for chat completion can be cancelled cleanly when ViewModel is destroyed, without leaving native inference threads running
If this fails: if user rapidly switches between chat screens or force-closes app during generation, native MLCEngine threads may continue consuming GPU resources until process death
android/MLCChat/app/src/main/java/ai/mlc/mlcchat/AppViewModel.kt:viewModelScope.launch usage
assumes Android app has storage permissions and the hardcoded path '/storage/emulated/0/Android/data/ai.mlc.mlcchat/files/' is writable on all Android versions
If this fails: on Android 11+ with scoped storage, app may not have write access to this path causing weight file installation to fail silently
android/MLCChat/bundle_weight.py:device_weihgt_dir path
assumes UUID.randomUUID() generates unique identifiers across all chat sessions and app restarts for message tracking
If this fails: while UUID collision is extremely unlikely, if it occurs, message updates could overwrite wrong messages in UI causing user confusion
android/MLCChat/app/src/main/java/ai/mlc/mlcchat/AppViewModel.kt:UUID generation for message IDs
assumes GlobalScope coroutines are appropriate for MLCEngine operations and will not prevent proper app lifecycle cleanup
If this fails: GlobalScope coroutines survive activity destruction, potentially keeping MLCEngine references alive and preventing proper GPU memory cleanup
android/MLCEngineExample/app/src/main/java/ai/mlc/mlcengineexample/MainActivity.kt:GlobalScope.launch usage
See the full structural analysis of mlc-llm: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of mlc-ai/mlc-llm →Frequently Asked Questions
What does mlc-llm assume that could break in production?
The one most likely to cause trouble: assumes image URIs passed to MessageData always point to valid, readable image files that can be decoded by BitmapFactory If this fails, if URI points to corrupted file, network location, or non-image content, BitmapFactory.decodeStream() returns null causing NullPointerException when converting to base64 string
How many hidden assumptions does mlc-llm have?
CodeSea found 10 assumptions mlc-llm relies on but never validates, 4 of them critical, spanning Domain, Resource, Contract, Environment, Scale, Temporal, 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.