Preview limitations

The browser preview runs the DataMind Oda app inside one dedicated Web Worker in a browser page, for preview deployments and packaging checks. It is not a desktop run of Oda: parts of the environment are missing or replaced, and this page lists what to expect before you rely on something. How the preview starts and mounts its data is on Browser preview.

What the preview does not carry

• Nothing installs. No package manager runs in the preview and no native dependency is built.
• No Node programs. A program that would run as a Node process cannot execute: the preview reports a Node executable path, but nothing can start it, so the program fails before it can launch.
• No Office conversion. Converting an Office document needs the app's own engine, which the preview does not carry.
• Plain-text session logs. Logs are written as plain text, one JSON object per line; the compressed form is never used.
• A shell, but not bash. The preview's shell is its own interpreter, not bash. It has no loops, functions, case, job control or process substitution; a trailing & runs its command to completion in place; sed runs substitution scripts only; pattern matching is JavaScript regular expressions; and the command set is coreutils only, with no git and no network tools. Commands, expansions and exit codes are on The preview shell.
• Filesystem-level confinement. Command confinement in the preview is a boundary of its own filesystem, not kernel-level enforcement.
• Structural stubs. node:dns/promises, node:vm, node:net, node:sqlite and node:worker_threads are placeholders. They load so that features which mention them still start, and every call they receive is refused.

When missing code is called

Pieces the preview does not carry load quietly and refuse when a call reaches them. The refusal names the module and the symbol and says it is not available in the worker host; it is written to the console first, and then the call fails. A console line looks like this:

node:zlib.gzipSync is not available in the worker host

What a refusal covers:

• Compression. The gzip and Zstandard codecs are not carried; every compress and decompress call is refused.
• Hashing. Only sha1, sha256 and sha512 can be created; any other algorithm is refused by name.
• Outbound HTTP. request and get are refused and point to fetch instead.
• Module tooling. TypeScript type stripping and module registration are not available.
• Command-line parsing. parseArgs is not available.
• Async tracking. Creating an async hook is not available.
• Windows paths. The Windows forms of the path module are unreachable (node:path.win32.<name> is unreachable); the preview reports the platform as linux.
• Sockets and DNS. Socket writes, socket ends, servers and client connections are refused; client websockets are not available; and a DNS lookup is refused because the preview has no resolver.

What the console prints beyond these refusals is collected on Preview diagnostics.

Replaced packages

Some dependencies are replaced with small stubs rather than missing at the module level. Each stub loads quietly, and it refuses when it is called:

• The process runner. Refuses every call; it is why no package manager runs and no native dependency is built in the preview.
• The image library. Refuses by default, so resizing and transcoding images do not run. The attachment handling around it still loads; only the resize attempt fails.
• The pseudo-terminal. Spawning and opening a terminal are refused; the preview has no terminal of this kind.
• The Office converter. Rejects with the code unavailable when a converter is created, because conversion needs the app's engine.
• The native-library bridge. Refuses a type it does not know.
• The file-search helper. Answers with a path string that nothing can execute; a search that tries fails in the command layer, not in the helper.

The filesystem it works in

• No symbolic links. Creating a symbolic link and reading through one are refused, and a check for a symbolic link always answers false.
• Permissions are not enforced. Permission bits are stored and reported, so tools that read them see normal values, but nothing is enforced: the filesystem reads and writes as its owner.
• Timestamps always move forward. A change moves a file's modification time forward, so two writes in the same millisecond still differ; that is how the preview tells an older write from a newer one.
• Watchers see only the preview's filesystem. A file watcher reports changes made during the run; content that was in place when it started is not replayed as changes.
• What an overlay cannot change. An overlay may replace files only under the home and workspace directories. Configuration and module code cannot be replaced this way, and a configuration edit lasts only for the current run of the preview. Fixtures and their overlays are on Preview fixtures and sample data.

The environment code sees

• A fixed platform. Code inside the preview sees linux on x64 whatever your machine is, a single process, no CPU count or network interfaces from the machine, output that is never a terminal, and a Node version that is a placeholder rather than a real release.
• Browser-oriented module resolution. Modules resolve with the conditions browser, require, import and default; the plain node condition is deliberately absent, so a package resolves the way a browser build expects.
• An image must match the build. A preview image whose recorded build differs from the running build is refused when it mounts, with a message that asks for a rebuild.

Questions, answered

Can I install npm packages in the preview?

No. The process runner that would fetch and install dependencies refuses every call, so no package manager runs and no native dependency is built. Install packages in a desktop run of Oda instead.

Why does my Node program not run in the preview?

Programs that would run as a Node process cannot start: the preview reports a Node executable path, but nothing can execute it, so the program fails before it can launch.

What happens when code calls something the preview does not carry?

The call is refused with a message that names the module and the symbol and says it is not available in the worker host. The line is written to the console first, and then the call fails. Because the missing pieces load quietly, you meet a refusal only when a call actually reaches one.

Which Node modules are stubbed in the preview?

node:dns/promises, node:vm, node:net, node:sqlite and node:worker_threads are structural stubs, and several individual symbols elsewhere are missing, including the compression codecs and most hash algorithms. Every call to them is refused.

Why do network calls fail in the preview?

The preview carries no sockets and no DNS resolver. Socket writes, socket ends, servers and client connections are refused, client websockets are not available, and a DNS lookup is refused. Outbound request and get are refused too; they point to fetch instead.

Can I convert an Office document in the preview?

No. Conversion needs the app's own engine, which the preview does not carry, and the converter rejects with the code unavailable.

Do image attachments still work in the preview?

Yes. The attachment handling around the image library still loads; it is resizing and transcoding that refuse, so only that step fails.

Can I create a symbolic link in the preview?

No. The preview's filesystem has no symbolic links: creating one and reading through one are refused, and a check for a symbolic link always answers false.

Are file permissions enforced in the preview?

No. Permission bits are stored and reported, so tools that read them see normal values, but they are never enforced: the preview's filesystem reads and writes as its owner.

Why does a file's timestamp change on every write?

Timestamps increase strictly per file, so two writes in the same millisecond still differ. That is how the preview tells an older write from a newer one.

What platform does the preview report?

A fixed one: linux on x64 whatever your machine is, one process, no CPU count or network interfaces from the machine, and output that is never a terminal. The Node version it reports is a placeholder, and the Windows forms of the path module are unreachable because of the platform it reports.

Are session logs compressed in the preview?

No. They are written as plain text, one JSON object per line; the compressed form is never used.