Hidden Assumptions in pocketbase
11 assumptions this code never checks · 4 critical · spanning Scale, Resource, Ordering, Contract, Domain, Temporal, Environment
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at pocketbase/pocketbase 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".
Large legitimate file uploads fail with cryptic errors, forcing users to split files or find workarounds, while the limit may be too permissive for memory-constrained environments
Backup listing fails with timeout errors on slower storage systems or when many backup files exist, making backups appear unavailable even when they exist
API returns success status but subsequent download attempts fail because backup file isn't yet accessible on eventually-consistent storage backends like S3
Show everything (8 more)
JavaScript runtime pool of 15 pre-warmed instances is sufficient for all concurrent hook executions under typical load, with no mechanism to adapt to actual concurrency patterns
If this fails: Under high load, requests queue waiting for available JS runtime instances, causing response time spikes and potential timeouts for legitimate requests
examples/base/main.go:hooksPool flag
Relation expansion is hard-coded to 6 levels maximum depth with no configuration override, assuming this depth is sufficient for all data modeling scenarios
If this fails: Complex relational data structures requiring deeper expansion silently truncate at level 6, returning incomplete data that may break client applications expecting full object graphs
ui/src/apiPreview/expandInfo.js:6-levels depth limit
The active backup flag in the store is properly cleaned up when backup operations complete or fail, with no timeout mechanism for stuck backup processes
If this fails: If a backup process crashes or hangs without clearing the flag, all subsequent backup attempts permanently fail with 'another backup process started' error until manual intervention
apis/backup_create.go:StoreKeyActiveBackup check
The default public directory exists and is readable by the process, with no fallback strategy if the directory is missing or has wrong permissions
If this fails: Static file serving fails completely if the public directory is misconfigured, potentially breaking admin UI and custom frontend applications with no clear error message
examples/base/main.go:defaultPublicDir() and file serving
Backup file uploads can complete within the HTTP request timeout regardless of file size, available bandwidth, or filesystem performance
If this fails: Large backup uploads timeout and fail, leaving partial files in storage and no way for clients to resume uploads
apis/backup_upload.go:fsys.UploadFile operation
All backup files in the filesystem have valid modification times and size metadata that can be read without errors
If this fails: Backup listing fails if any backup file has corrupted metadata or is in an inconsistent state during upload, making all backups appear unavailable
apis/backup.go:backupFileInfo struct
Filter expressions have reasonable complexity limits that prevent expensive operations, but no explicit validation of expression depth or computation cost is visible
If this fails: Complex nested filter expressions could cause performance degradation or resource exhaustion during SQL query generation and execution
ui/src/apiPreview/filterSyntax.js:filter expression parsing
The excerpt modifier always operates on text fields and handles edge cases like null values, binary data, or extremely long strings gracefully
If this fails: Field excerpting may fail or produce unexpected output when applied to non-text data types, potentially exposing sensitive data or causing client rendering issues
ui/src/apiPreview/fieldsInfo.js:excerpt modifier
See the full structural analysis of pocketbase: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of pocketbase/pocketbase →Frequently Asked Questions
What does pocketbase assume that could break in production?
The one most likely to cause trouble: DefaultMaxBodySize constant provides adequate limits for file uploads across all deployment environments, but the actual value is not visible and may be insufficient for legitimate use cases like bulk data imports or high-resolution media uploads If this fails, Large legitimate file uploads fail with cryptic errors, forcing users to split files or find workarounds, while the limit may be too permissive for memory-constrained environments
How many hidden assumptions does pocketbase have?
CodeSea found 11 assumptions pocketbase relies on but never validates, 4 of them critical, spanning Scale, Resource, Ordering, Contract, Domain, Temporal, Environment. 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.