Summary
Self-hosters currently have no way to change three hardcoded size limits, and the only recourse is patching the minified dist (which we've had to do in production):
- Document open limit — 512 KiB (
DOCUMENT_OPEN_BYTE_LIMIT in @inkeep/open-knowledge-core, enforced in packages/server/src/persistence.ts)
- Collab WebSocket message cap — 1 MiB (
MAX_COLLAB_MESSAGE_BYTES in packages/app/src/server/hocuspocus-plugin.ts, used both as ws maxPayload and the per-message check)
- Client-side open check — 512 KiB mirrored in the web bundle ("OpenKnowledge currently opens files up to 512 KiB")
A doc that legitimately exceeds 512 KiB can't be opened at all, and raising limit 1 alone isn't enough — the same value is enforced independently at the transport layer and in the client, so all three must move together. A single config key (e.g. documents.maxOpenBytes, with the collab cap derived as 2×) would remove the need for dist patches entirely.
Field report that motivated this
Running 0.38.4 self-hosted, we hit the ./-prefixed --cacheinfo path failure on a root-level doc (Invalid path './README'), which broke checkpoint persistence and let a bridge merge loop duplicate the document ~650× (3.3 KiB → 2.1 MB → 4.2 MB across reconnects). Two observations that may be useful:
- The fix that landed in #2962 today (root normalization before
update-index --cacheinfo) addresses the trigger — thank you; we'd patched the same two call sites locally and can confirm it stops the loop when combined with clearing the stale client.
- The 512 KiB open limit acted as an accidental circuit breaker for that runaway (the doc stopped loading once it crossed the cap). If limits become configurable, consider keeping a separate, explicitly-named runaway guard (e.g. "refuse to load a doc that grew >N× since last persist") so raising the open limit doesn't silently remove that protection — that's the one thing the hardcoded cap was quietly doing well.
Environment
@inkeep/open-knowledge 0.38.4 (npm), Ubuntu server, systemd user service, browser clients over SSH tunnel.
Happy to contribute the config-plumbing PR if the shape above (single key + derived collab cap + explicit runaway guard) sounds right to the maintainers.
Summary
Self-hosters currently have no way to change three hardcoded size limits, and the only recourse is patching the minified dist (which we've had to do in production):
DOCUMENT_OPEN_BYTE_LIMITin@inkeep/open-knowledge-core, enforced inpackages/server/src/persistence.ts)MAX_COLLAB_MESSAGE_BYTESinpackages/app/src/server/hocuspocus-plugin.ts, used both aswsmaxPayloadand the per-message check)A doc that legitimately exceeds 512 KiB can't be opened at all, and raising limit 1 alone isn't enough — the same value is enforced independently at the transport layer and in the client, so all three must move together. A single config key (e.g.
documents.maxOpenBytes, with the collab cap derived as2×) would remove the need for dist patches entirely.Field report that motivated this
Running 0.38.4 self-hosted, we hit the
./-prefixed--cacheinfopath failure on a root-level doc (Invalid path './README'), which broke checkpoint persistence and let a bridge merge loop duplicate the document ~650× (3.3 KiB → 2.1 MB → 4.2 MB across reconnects). Two observations that may be useful:update-index --cacheinfo) addresses the trigger — thank you; we'd patched the same two call sites locally and can confirm it stops the loop when combined with clearing the stale client.Environment
@inkeep/open-knowledge0.38.4 (npm), Ubuntu server, systemd user service, browser clients over SSH tunnel.Happy to contribute the config-plumbing PR if the shape above (single key + derived collab cap + explicit runaway guard) sounds right to the maintainers.