testthat::expect_snapshot_value: Can't find `bottom` on the call tree. Backtrace:

[kapsner]

testthat::expect_snapshot_value results in the error below when running the Github-Actions in the repository of the DQAgui R package, however, only for the runners macOS-latest(release) and ubuntu-latest(devel) (windows-latest(release) and ubuntu-latest(release) are both passing without this error).

This error is difficult to debug, as it is not reproducible running devtools:test() on my local machine.

Error in `trace_back(top = getOption("testthat_topenv"), bottom = trace_env)`: Can't find `bottom` on the call tree.
Backtrace:
▆
  1. ├─shiny::testServer(...) at test-shinyapp.R:32:2
  2. │ ├─shiny:::withMockContext(...)
  3. │ │ ├─shiny::isolate(...)
  4. │ │ │ ├─shiny::..stacktraceoff..(...)
  5. │ │ │ └─ctx$run(...)
  6. │ │ │   ├─promises::with_promise_domain(...)
  7. │ │ │   │ └─domain$wrapSync(expr)
  8. │ │ │   ├─shiny::withReactiveDomain(...)
  9. │ │ │   │ └─promises::with_promise_domain(...)
 10. │ │ │   │   └─domain$wrapSync(expr)
 11. │ │ │   │     └─base::force(expr)
 12. │ │ │   └─env$runWith(self, func)
 13. │ │ │     └─shiny contextFunc()
 14. │ │ │       └─shiny::..stacktraceon..(expr)
 15. │ │ ├─shiny::withReactiveDomain(...)
 16. │ │ │ └─promises::with_promise_domain(...)
 17. │ │ │   └─domain$wrapSync(expr)
 18. │ │ │     └─base::force(expr)
 19. │ │ └─withr::with_options(...)
 20. │ │   └─base::force(code)
 21. │ └─rlang::eval_tidy(quosure, mask, rlang::caller_env())
 22. └─testthat::expect_snapshot_value(...) at test-shinyapp.R:59:4
 23.   └─testthat:::expect_snapshot_helper(...)
 24.     └─testthat::expect(...)
 25.       └─rlang::trace_back(top = getOption("testthat_topenv"), bottom = trace_env)
 26.         └─rlang:::trace_find_bottom(bottom, frames)
 27.           └─rlang::abort(msg, call = call)

Does anyone have an idea, why this error occurs and maybe even how to fix it?

Thanks in advance, Lorenz

[DanChaltiel]

I also got this a bit confusing error and I think I could reproduce it.

In my case, it happened with expect_warning() when 2 conditions are met:

• the wrong class is specified
• it is called after a magrittr pipe

Here is a MRE:

library(magrittr)
library(testthat, warn.conflicts=FALSE)
f = function() {
  rlang::warn("foobar", class="x")
}

expect_warning(f(), class="y")
#' Warning: foobar
#' Error: `f()` did not throw the expected warning.
f() |> expect_warning(class="y")
#' Warning: foobar
#' Error: `f()` did not throw the expected warning.
f() %>% expect_warning(class="y")
#' Warning: foobar
#' Error in `trace_back()`:
#'   ! Can't find `bottom` on the call tree.
#' Run `rlang::last_error()` to see where the error occurred.

Trace

rlang::last_error()
#'<error/rlang_error>
#'  Error in `trace_back()`:
#'  ! Can't find `bottom` on the call tree.
#'---
#'Backtrace:
#' 1. f() %>% expect_warning(class = "y")
#' 2. testthat::expect_warning(., class = "y")
#' 3. testthat:::expect_condition_matching(...)
#' 4. testthat::expect(...)
#' 5. rlang::trace_back(top = getOption("testthat_topenv"), bottom = trace_env)
#'Run `rlang::last_trace()` to see the full context.
rlang::last_trace()
#'<error/rlang_error>
#'Error in `trace_back()`:
#'! Can't find `bottom` on the call tree.
#'---
#'  Backtrace:
#'  ▆
#'1. ├─f() %>% expect_warning(class = "y")
#'2. └─testthat::expect_warning(., class = "y")
#'3.   └─testthat:::expect_condition_matching(...)
#'4.     └─testthat::expect(...)
#'5.       └─rlang::trace_back(top = getOption("testthat_topenv"), bottom = trace_env)
#'6.         └─rlang:::trace_find_bottom(bottom, frames)
#'7.           └─rlang::abort(msg, call = call)

[ezraporter]

For future travelers: I was running into an issue similar to @kapsner but I eventually found that the Error in trace_back(... error was only occurring when my snapshot test was actually failing. Fixing the test resolved the error. (Maybe also useful info for determining the source of the bug.)

If you're using GH actions, I found the upload-snapshots parameter of check-r-package to be very helpful for debugging snapshot test failures that only occur in CI and not locally.

[olivroy]

Occured to me today. If working on version control, deleting the original snapshot file is useful to use git to see what changed in the snapshot, so that the underlying error can be more easily identified