Error Pages

Inspecting variables in the REPL

The REPL evaluates expressions against a snapshot of the environment captured the moment the request failed. The controller and request state is always present — this (including any @ivars you set), params, req, and cookies. When the error happened while a template was rendering, the data you passed to render(...) is captured too: each key as a top-level name, and the whole hash as _view_data.

def show
  @page_owner = "Olivier"
  render("posts/show", {
    "title": "Hello",
    "posts": Post.all()
  })
end

# Then, in the error-page REPL:
title                     # => "Hello"
posts.map(fn(p) p.title)  # locals are real values — run expressions, not just reads
_view_data.title          # same data, under the _view_data object
this.page_owner           # controller instance vars

When a view errored, the page also shows a View Locals panel with a one-click button per render(...) local (plus an All locals button for _view_data), so you don't have to remember the names.

A name passed to render(...) that collides with a controller-scope variable is shadowed by the controller value at the top level — reach the view's copy under _view_data.<key> (the View Locals buttons do this for you). Variables created inside the template (a <% total = ... %> assignment, a loop variable) are not part of the snapshot; only the locals you passed into render(...) are.

Error logging to stderr

For every 500 the server writes a multi-line block to stderr — useful when you only have access to container / journald logs. This fires in both --dev and --no-dev so failures show up in your terminal during development the same way they do in production. The first [ERROR] request_id=… METHOD PATH - msg line is preserved from earlier versions so existing log parsers keep working.

[ERROR] request_id=05dedb29-… GET /users/42 - Type error: cannot index null with string at 7:13
  stack:
    show at app/controllers/users.sl:92
    find at app/models/user.sl:14
  request:
    {
      "body": "[REDACTED]",
      "headers": { ... },
      "method": "GET",
      "params": { ... },
      "path": "/users/42",
      "query": { ... },
      "session": "N/A"
    }
  env: {"current_user": null, "user_id": null, ...}

Secrets are redacted in the stderr snapshot: Authorization and cookie / token / password params show [REDACTED]; the request body is always redacted. The env: line is filtered by the same rule, so a local variable named like a secret (password, api_key, access_token, …) is logged as [REDACTED] instead of by value. Failure context is written only to stderr — never to the production HTML page.

Correlate a customer's Error ID to a stderr block by searching the logs for request_id=<that id>.

Production Mode Ensures:

• Custom error pages are used
• Auth headers, tokens, passwords, and request bodies are redacted
• Error IDs are generated for support reference