Make defaultErrorHandler more verbose in the Connect application logs

[slodge-work]

Make defaultErrorHandler more verbose in the Connect application logs

[meztez]

I would like to bring back the focus to the issue you raised here before addressing the larger comment. I provided an explanation above, I would like to know if this explanation fits the reality you are experiencing so the right channels can be made aware of the issue.

Also, I would like to address the whole error messaging part in the upcoming release. It has been mentioned in multiple issues before and is something users would greatly benefit from.

@slodge Your comments sometimes come across with charged emotions? I do not know how to express it more plainly. All contributors here are doing this to give back to the community. I know you have issues with the velocity of features delivery. What I can say is you will get back what you put in from the communications you use online.

Hopefully we can have a more fun discourse over the coming months. You are already bringing about changes and your help is greatly appreciated. Have a great weekend

[meztez]

@slodge-work Can you see the error if you download the log from connect instead of the log UI?

I've tested on the latest connect version, the UI display a blank line but the log file contains the error.

library(plumber)

#* @apiTitle Plumber Example API
#* @apiDescription Plumber example description.

#* Echo back the headers
#* @get /bob
function() {
  stop("bob")
}

[meztez]

I think this is a connect UI issue. Looking at the source for the page, the error log is in the source. I think it would need to be converted to html entities for the browser to display it correctly.

[slodge]

I'll leave the internal plumber-vs-connect finger pointing about stdout/err displays and downloads to posit -- can one of her posit contributors here flag an appropriate product rep?

---

On a technical level, i've been led to believe that print is not the correct option here - see https://stackoverflow.com/a/36700294 for one explanation.

However, assuming there are good reasons for insisting on print in plumber, then please close this as "won't fix".

---

My motivation;

As a user who gets to debug real world 500 errors, often in code written by other people a long time ago; often under time pressure; and often without easy reproducibility, I'd typically love more information in these situations

• the error message is a good start,
• the rlang::backtrace is often super helpful,
• the path of the endpoint along with a summary of parameters is great too.
  • (advanced - probably a separate issue) I understand for security reasons that sometimes parameter values shouldn't be logged - maybe some know of sensitive attribute/flag could be added to "secret" parameters to help prevent them leaking.

Additionally (another separate issue) it would be great to use structured logging to help enable search in eg splunk. For connect hosting, that is an issue open with connect support - it's on the backlog but I'm afraid I don't have any URL or reference for it. For eg docker hosting it might be something plumber could consider enabling/assisting.

[slodge]

... That was a lot written, but really I'd still quite like to start with one word changing print to message :)

[slodge]

Thanks Bruno

I think you misunderstood my last message. My suggestion was that your observation was to do with the differences between print and message - one writes to stdout, the other to stderr - and that there was a simple path available here for plumber to use message instead of print.

I'm afraid I can't provide more insight into the inner workings of Connect here - it's closed source.

However, I can test by publishing an api like

library(plumber)

#* @apiTitle Plumber Example API
#* @apiDescription Plumber example description.

#* Echo back the input
#* @param msg The message to echo
#* @get /echo
function(msg = "") {
  print("Hello")
  message("World")
    list(msg = paste0("The message is: '", msg, "'"))
}

If I then look at stdout vs stderr I see:

As before, I did find https://stackoverflow.com/a/36700294 quite informative and useful about when print and message should be used, but I respect if plumber and/or Connect have different opinions here.

---

The additional suggestions I made - considering including backtrace, including request details and considering adding structured logging - to me do seem appropriate under the title of "Make defaultErrorHandler more verbose in the Connect application logs" - but I apologise if you feel that these weren't on topic.

---

As for your "emotional" call, I personally feel I've tried to contribute intelligently, politely and positively at all times during the last year in which I've tried to engage with this project. However, I do agree there are communication and velocity issues in this project.

Based on this, and especially based on wanting this project to be healthy and wanting everyone to enjoy contributing, I'm going to step back from contributing further here. It's great to hear that a future release is now planned. I wish you and the team all the best with the work. Please do reach out if there's anything you would like from me, but otherwise I'll step back to being a CRAN based user of plumber 👍

[meztez]

plumber to use message instead of print.

message output to stderr, and only output the condition message. print will wrap the condition class, the call and the error message between < >. See print.condition.

Like @slodge mentioned, there is a simple way to deal with this, replacing the default print with message. Taking into account the different in log location (stdin and stdout), plus the < > wrapping, it might be a good idea to have a better logging in place specifically for connect?

As it is, the current print is not useful at all for user on connect. Will open a ticket with the connect team also.

[slodge-work]

Cool - I saw no evidence of <> in my test stdout/stderr files - but I'm happy switching to message works - especially as that is what we use in our custom error handler code.

As there are plenty of other issues around logging, let's move any other discussion to those in the interest of productive, healthy and fun conversation and contribution.

Closing this ticket out 👍