DocsWorking with Rahti
Diagnostics
While development mode is active, Rahti makes frontend failures visible to tools that can read the workspace but cannot see browser DevTools — as JSON Lines in .rahti/dev.log.
One file, one server session
.rahti/dev.log is newline-delimited JSON: one complete object per line. It is truncated when a new development server process initialises, so it describes the current session, and .rahti is gitignored in both the framework repository and every scaffolded application. Browser diagnostics are also mirrored, in concise form, to the server terminal.
What is captured
The injected development client starts before deferred module scripts — including public/js/main.js — execute. That ordering is what lets it wrap the console and install global error listeners before PulsePoint mounts.
From the browser
console.warn(…)andconsole.error(…)- uncaught JavaScript exceptions
- unhandled Promise rejections
- script, stylesheet, image and other resource load failures
From the server
- fallible page responses and handler panics
- failed and panicking RPCs
- upload spooling failures and invalid upload limits
- RPC stream serialization failures, CSRF random-source failures
A browser record
{"kind":"browser","receivedAtMs":1785300000000,"boot":"...","level":"error",
"message":"[PP-ERROR] Handler failed: ...","stack":"Error: console.error\n ...",
"url":"http://127.0.0.1:3000/counter","source":"http://127.0.0.1:3000/counter",
"line":42,"column":17,"component":"page_7db1cef0 (section)",
"timestamp":"2026-07-29T12:00:00.000Z"}| Field | Meaning |
|---|---|
| kind | browser or server. |
| receivedAtMs | Server receipt time. |
| boot | The development server process that received it. |
| level | warn, error, uncaught, unhandledrejection, or resource-error. |
| message | Safely serialized console arguments, or the error reason. |
| stack | The browser stack, when there is one. |
| url | The document URL. |
| source, line, column | The browser-reported source location, when available. |
| component | The best-effort active pp-component boundary. |
| timestamp | Browser capture time. |
Console APIs do not expose their call-site filename separately, so the captured stack is the source-location evidence. The PulsePoint bundle ships minified and without a source map, so a stack that lands inside it gives a bundle line and nothing more readable — identify such a record by its message text and by the component boundary it came from.
A server record
{"kind":"server","receivedAtMs":1785300000000,"boot":"...","level":"error",
"target":"rpc","message":"rahti: rpc 400 Bad Request — text cannot be empty"}target identifies the framework subsystem: page, page-panic, rpc, rpc-panic, rpc-upload, rpc-stream, upload-config, or csrf.
Limits, and what the bridge is not
- one browser request is limited to 128 KiB;
- a batch is limited to 50 entries;
- individual accepted string fields are limited to 16 KiB;
- the client serializes circular values and truncates large console arguments;
- delivery failures are silent, to prevent recursive "logging failed" warnings;
- the endpoint and the injected client exist only when development mode is enabled.
The bridge is diagnostic, not durable telemetry: a browser closing during a network failure can lose its final batch.
The debugging loop
- start the application with
cargo dev, or another dev-enabled run; - reproduce the behaviour in a browser;
- read
.rahti/dev.logfrom the beginning of the current session; - group records by
boot, URL, component and message; - use
source, line and column when present; otherwise read the stack; - a message from the runtime names the condition it detected — read it against the markup and script of the reported component;
- fix the smallest owning block and rerun the reproduction;
- confirm no new matching record appears after the server restarts.
# The log is JSON Lines: one object per line, truncated on each dev restart.
cat .rahti/dev.log
# Only this session's browser errors.
grep '"kind":"browser"' .rahti/dev.log | grep '"level":"error"'
# What one component reported.
grep 'page_7db1cef0' .rahti/dev.log