Hidden Assumptions in documenso
13 assumptions this code never checks · 5 critical · spanning Shape, Domain, Ordering, Contract, Resource, Temporal, Environment, Scale
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at documenso/documenso 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 a dataset has fewer data points than labels, array access will return undefined and push operations will create sparse arrays with holes, corrupting chart visualization
in non-English locales, parsing fails silently returning invalid DateTime, causing the function to return early without zero-padding, breaking chart consistency
if token expires or becomes invalid mid-session, subsequent authentication operations fail silently or with confusing errors, leaving users unable to complete signing
Show everything (10 more)
assumes labels array contains chronologically ordered month strings, but never validates this ordering
If this fails: if months are out of order, the minus/plus month calculations add zero months in wrong positions, creating nonsensical time series with months appearing multiple times
apps/openpage-api/lib/add-zero-month.ts:addZeroMonth
assumes window.location.href assignment in signOut/signOutSession methods will always succeed and complete navigation
If this fails: in restricted iframe contexts or when CSP blocks navigation, the redirect fails silently leaving users in inconsistent auth state thinking they're signed out but still having active sessions
packages/auth/client/index.ts:AuthClient
assumes subscription.status reflects real-time subscription state, but status is only updated through webhook events or periodic syncing
If this fails: recently cancelled or expired subscriptions may show as active for minutes or hours, allowing users to exceed limits they should be restricted to, potentially causing billing discrepancies
packages/ee/server-only/limits/server.ts:getServerLimits
assumes NEXT_PRIVATE_DATABASE_REPLICA_URLS contains valid, reachable database URLs when present, but never validates URL format or connectivity
If this fails: invalid replica URLs cause Prisma to fail at runtime during read operations, potentially taking down the entire application when read replicas are configured incorrectly
packages/prisma/index.ts:prismaWithReplicas
assumes remember() utility creates singleton instances that are safe across concurrent requests, but doesn't handle memory cleanup or connection pool limits
If this fails: in high-concurrency scenarios, the global prisma client singleton may exhaust database connection pools or accumulate memory, causing degraded performance or crashes
packages/prisma/index.ts:remember
assumes email.toLowerCase() is sufficient for email normalization, but doesn't handle unicode characters, punycode domains, or plus-addressing
If this fails: users with identical emails in different unicode forms or with plus-addressing can create duplicate accounts, causing authentication confusion and potential data leakage between accounts
packages/prisma/seed/users.ts:seedUser
assumes AppError.parseError can handle any error format returned by the session endpoint, but error response shapes may vary by HTTP status or server state
If this fails: unexpected error formats cause AppError.parseError to throw its own errors, masking the original authentication failure and making debugging authentication issues extremely difficult
packages/auth/client/index.ts:getSession
assumes environment variable contains a valid number string when present, but Number() conversion can return NaN for invalid inputs
If this fails: invalid size limits cause document upload validation to use NaN, which fails all comparisons, either blocking all uploads or allowing unlimited sizes depending on comparison logic
packages/lib/constants/app.ts:NEXT_PUBLIC_DOCUMENT_SIZE_UPLOAD_LIMIT
assumes passkey data from trpc queries remains valid throughout the signing session without checking for revoked or expired passkeys
If this fails: if passkeys are revoked on another device or expire during a long signing session, authentication attempts fail with cryptic WebAuthn errors instead of prompting for alternative auth methods
apps/remix/app/components/general/document-signing/document-signing-auth-provider.tsx:passkeyData
assumes organisation.subscription and organisation.organisationClaim are always present when organisation exists, based on database relations
If this fails: if database integrity is compromised or migrations create orphaned organisations, accessing subscription or claim properties throws null reference errors during limit checks, blocking document operations
packages/ee/server-only/limits/server.ts:getServerLimits
See the full structural analysis of documenso: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of documenso/documenso →Frequently Asked Questions
What does documenso assume that could break in production?
The one most likely to cause trouble: assumes all datasets in transformedData.datasets have the same length data arrays as the labels array, but only verifies labels.length === 0 If this fails, if a dataset has fewer data points than labels, array access will return undefined and push operations will create sparse arrays with holes, corrupting chart visualization
How many hidden assumptions does documenso have?
CodeSea found 13 assumptions documenso relies on but never validates, 5 of them critical, spanning Shape, Domain, Ordering, Contract, Resource, Temporal, Environment, 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.