What causes "failed to evaluate expression" in denoland/deno?

Re-run the same expression; transient inspection glitches usually clear on the next evaluation.

denoland/deno · error · AnyError

failed to evaluate expression

Error message

failed to evaluate expression

What it means

Thrown by the REPL's result formatter (get_eval_value in cli/tools/repl/session.rs). After an expression evaluates, the REPL calls its internal inspectArgs helper over the Chrome DevTools protocol (Runtime.callFunctionOn) to stringify the result; the error fires when the response carries neither a string `value` nor a `description` on the returned RemoteObject, so nothing is printable. It is an internal inspection round-trip failure, not a type error in the evaluated expression itself.

Solutions

Re-run the same expression; transient inspection glitches usually clear on the next evaluation.
Bypass the inspector formatter with an explicit conversion: JSON.stringify(x), String(x), or x?.toString().
Restart the REPL (deno) so the internal inspectArgs helper is re-created.
If one specific expression reproduces it every time, minimize it and report at https://github.com/denoland/deno/issues.

Example fix

// before (REPL): inspector formatting of an exotic object fails
> config
error: failed to evaluate expression

// after: force a primitive yourself
> JSON.stringify(config, null, 2)

Defensive patterns

Strategy: retry

Prevention

Avoid Ctrl-C while the REPL is formatting a result — interrupt before evaluation completes instead.
Prefer explicit JSON.stringify(value) / String(value) for Proxy objects or objects with throwing getters.
Restart the REPL if failures repeat within one session; it rebuilds the internal inspectArgs helper.

When it happens

Trigger: Evaluating an expression in the `deno` REPL whose inspect round-trip returns an empty RemoteObject: pressing Ctrl-C between evaluation and formatting, awaiting something that detaches or invalidates the execution context, or an object (Proxy, throwing getter) whose inspection fails in a way that also breaks the catch branch of the injected function at session.rs:763-769.

Common situations: Interrupting the REPL while it formats a huge or deeply nested object; getter-heavy config objects; long-lived REPL sessions left open across a deno upgrade; REPL driven through wrappers that mangle stdout.

Related errors

AI-assisted analysis of denoland/deno@9ad36f7a2c (2026-08-20). Data as JSON: /api/errors/4247298af5a1aa64. Report an issue: GitHub.

Appendix: source

Thrown at cli/tools/repl/session.rs:779

    let response = self
      .call_function_on_repl_internal_obj(
        r#"function (object) {
          try {
            return this.inspectArgs(["%o", object], { colors: !this.noColor });
          } catch (err) {
            return this.inspectArgs(["%o", err]);
          }
        }"#
          .to_string(),
        std::slice::from_ref(evaluate_result),
      )
      .await?;
    let s = response
      .result
      .value
      .map(|v| v.as_str().unwrap().to_string())
      .or(response.result.description)
      .ok_or_else(|| anyhow!("failed to evaluate expression"))?;

    Ok(s)
  }

  async fn evaluate_ts_expression(
    &mut self,
    expression: &str,
  ) -> Result<TsEvaluateResponse, AnyError> {
    let tsx_result =
      parse_source_as(expression.to_string(), deno_ast::MediaType::Tsx);
    // Prefer a clean `.tsx` parse. Fall back to parsing as TypeScript when the
    // `.tsx` parse fails outright, or when it only recovered by inserting an
    // `Invalid` placeholder node (e.g. a TypeScript type assertion like
    // `<string>x` is misread as JSX in `.tsx`).
    let needs_ts_fallback = match &tsx_result {
      Ok(parsed) => {
        deno_resolver::emit::invalid_syntax_parse_diagnostics(parsed).is_some()
      }

View on GitHub (pinned to 9ad36f7a2c)