4-debugging.Rmd

---
title: "Debugging pipelines"
output: html_document
---

# Setup

Start with a fresh data store.

```{r}
library(targets)
tar_destroy()
```

Copy the starting `_targets.R` file into the working directory.

```{r}
tmp <- file.copy("4-debugging/initial_targets.R", "_targets.R", overwrite = TRUE)
```

Open this file for editing and verify that `source("4-debugging/functions.R")` appears near the top.

```{r}
tar_edit()
```

# Problem

This pipeline has a bug, and your job is to find and fix it.

```{r}
tar_make()
```

```{r}
tar_visnetwork()
```

To begin to search for clues, review the error message and warnings stored in the metadata.

```{r}
tar_meta(starts_with("run"), fields = c("error", "warnings"))
```

# Debugging with saved workspaces

We need more information, so we invoke `tar_make()` with workspaces enabled. First, open `_targets.R` for editing.

```{r}
tar_edit()
```

In `tar_option_set()`, set `workspace_on_error` to `TRUE`. The next time a target errors out, `targets` will save a workspace image file in `_targets/workspaces/`. (Alternatively, you could set `tar_option_set(workspace = c("target1", "target2"))` to always save workspaces for a specific set of targets.)

```{r, eval = FALSE}
# Do not run here.
tar_option_set(
  packages = c(
    "corrr",
    "keras",
    "recipes",
    "rsample",
    "tidyverse",
    "yardstick"
  ),
  workspace_on_error = TRUE
)
```

Now, run `tar_make()` and let the error happen again.

```{r}
tar_make()
```

Confirm the name of the failed target.

```{r}
library(tidyverse)
failed <- tar_meta(fields = error) %>%
  na.omit() %>%
  pull(name) %>%
  head(n = 1)
print(failed)
```

Confirm that a saved workspace exists for this target.

```{r}
list.files("_targets/workspaces")
```

Load the workspace of this target.

```{r}
tar_workspace(run)
```

The required packages, functions, RNG seed, and upstream dependencies (`churn_data` and `churn_recipe`) are now in your global environment.

```{r}
ls()
```

Now, you can more easily reproduce the error and search for the cause.

```{r}
test_model(act1 = "sigmoid", units1 = 32, churn_data, churn_recipe)
```

# Your turn

Go find that error and fix it! You may have to explore the `4-debugging/functions.R` file.

```{r}
usethis::edit_file("4-debugging/functions.R")
```

You have completed the exercise when `tar_make()` runs without error. Once you are done, you may remove the workspace files either with `tar_destroy(destroy = "workspaces")` or `unlink("_targets/workspaces/", recursive = TRUE)`.

# Tip: workspaces option

If you want to save workspaces for a targets that do not necessarily error out, simply supply the names to the `workspaces` argument of `tar_option_set()`.

# Tip: interactive debugging

Base utilities `debug()`, `debugonce()`, `undebug()`, and `browse()` are extremely helpful for debugging functions. More information on interactive debugging can be found at <https://rstats.wtf/debugging-r-code.html>.

```{r}
debugonce(test_model)
test_model(act1 = activations, units1 = units, churn_data, churn_recipe)
```

Once you are inside the debugger, you can access objects in the runtime environment and gradually step through the code. Press `n` to advance to the next line, and press `c` to continue on to the next breakpoint (place where the debuggger pauses). Press `Q` to exit the debugger.

# Built-in interactive debugging in `targets`

As an alternative technique, you can debug interactively while `tar_make()` is actually running. Set these options in `_targets.R`.

```{r}
tar_option_set(debug = "run", cue = tar_cue(mode = "never"))
```

Then, restart R and run `tar_make(callr_function = NULL)` in the R console (not in a chunk in this notebook). `targets` will drop you into an interactive debugger at the errored target. 

```{r}
# Copy and paste directly into the console.
# Do not run in this notebook. If you do, it will hang.
tar_make(callr_function = NULL)
```

Debugging this way is not always possible: for example, if you run `tar_make_clustermq()` to distribute your targets on a cluster and your target can only run on a remote compute node. However, it can often recreate the error more easily and quickly than the `error = "workspace"` approach.

# Dynamic branching

This short course covers dynamic branching in chapter 6. Both kinds of debugging (workspaces and interactive) support dynamic branching. Interface functions like `tar_option_set()` can accept either individual branches or whole patterns.