Ark: `harp_format()` errors on quosures

[DavisVaughan]

I'm not entirely sure how we got here in the first place, but this came from a private beta user https://github.com/posit-dev/positron-beta/discussions/19#discussioncomment-9407240

[R] 2024-05-12T16:18:40.325464000Z [ark-unknown] WARN crates/harp/src/utils.rs:102: `format()` method for <quosure/formula> should return the same number of elements.
[R] 2024-05-12T16:18:40.326057000Z [ark-unknown] WARN crates/ark/src/variables/variable.rs:299: Error while formatting variable: Error evaluating harp_format(~NULL): Unexpected length from `base::format()`.
[R] R backtrace:
[R] 1. safe_evalq(harp_format(~NULL), <environment>)
[R] 2. withCallingHandlers(list(out, NULL), error = handler)
[R] 3. harp_format(~NULL)
[R] 4. format_oo(x, ...)
[R] 5. format_fallback(x, ...)
[R] 6. stop("Unexpected length from `base::format()`.")

[R] 2024-05-12T16:16:16.793140000Z [ark-unknown] WARN crates/harp/src/utils.rs:102: `format()` method for <quosure/formula> should return the same number of elements.
[R] 2024-05-12T16:16:16.793596000Z [ark-unknown] WARN crates/ark/src/variables/variable.rs:299: Error while formatting variable: Error evaluating harp_format(~everything()): Unexpected length from `base::format()`.
[R] R backtrace:
[R] 1. safe_evalq(harp_format(~everything()), <environment>)
[R] 2. withCallingHandlers(list(out, NULL), error = handler)
[R] 3. harp_format(~everything())
[R] 4. format_oo(x, ...)
[R] 5. format_fallback(x, ...)
[R] 6. stop("Unexpected length from `base::format()`.")

[juliasilge]

This looks to be the same as #2801 to me. What do you think?

[DavisVaughan]

Reprex from #2801

library(ggplot2)

df <- data.frame(x = 1:10, y = rnorm(10))
p1 <- ggplot(data = df, mapping = aes(x=x,y=y)) + geom_point() + theme_bw()
p1

[lionel-]

Two actions we could take here:

• Add some handling for quosures so they display the expression and maybe the env id

• We could downgrade the offending WARN to a TRACE. The fallback handling works well I think so we shouldn't make it seem like there is something to fix necessarily. The backtrace is probably too distracting in user logs. I included one in this message to make it easier to identify which format classes don't conform to our assumptions. We could just include the class vector in the message instead.

[DavisVaughan]

In particular I noticed this when searching for Error in the log text, so removing the word Error would probably help a lot, as it makes it hard to find "real" problems

[juliasilge]

QA Notes

After we merge in https://github.com/posit-dev/ark/pull/483 and then bump ark, you can do something like:

x <- formula("y ~ a + b + c")

And no longer see anything in the logs like:

[R] R backtrace:
[R] 1. safe_evalq(harp_format(~NULL), <environment>)
[R] 2. withCallingHandlers(list(out, NULL), error = handler)
[R] 3. harp_format(~NULL)
[R] 4. format_oo(x, ...)
[R] 5. format_fallback(x, ...)
[R] 6. stop("Unexpected length from `base::format()`.")

As long as you have the default option for positron.r.kernel.logLevel. If you have that set to trace, then you will still see that in the logs.

[jonvanausdeln]

Verified Fixed

Positron Version(s) : 2024.08.0-77 OS Version(s) : Windows 11

Test scenario(s)

Messages don't show up in the logs, unless trace enabled... as expected

Link(s) to TestRail test cases run or created: