renderPlot() failure in Posit Cloud

[kilonovember]

I have developed a Shiny app which I deploy to Posit Cloud. The app works as expected on my computer, but when deployed to Posit Cloud, two ggplot images fail to render and are replaced with this:
Error: An error has occurred. Check your logs or contact the app author for clarification.
Otherwise the app works as on my local machine. I spent most of yesterday looking for answers with the help of Google Gemini, but with no success. Gemini suggested that the issue is a difference between the configuration on my computer and the Posit Cloud environment. Any help will be gratefully received.

[prubin]

What shows up in the log?

[kilonovember]

Here's the log. I'm posting all of it as I don't see anything that suggests a problem to me, but you may see what I don't:
2025-12-16T12:01:13-05:00 80: doTryCatch
2025-12-16T12:01:13-05:00 79: tryCatchOne
2025-12-16T12:01:13-05:00 78: tryCatchList
2025-12-16T12:01:13-05:00 77: tryCatch
2025-12-16T12:01:13-05:00 76: do
2025-12-16T12:01:13-05:00 75: hybrid_chain
2025-12-16T12:01:13-05:00 74: force
2025-12-16T12:01:13-05:00 73: withVisible
2025-12-16T12:01:13-05:00 72: withCallingHandlers
2025-12-16T12:01:13-05:00 71: domain$wrapSync
2025-12-16T12:01:13-05:00 70: promises::with_promise_domain
2025-12-16T12:01:13-05:00 69: captureStackTraces
2025-12-16T12:01:13-05:00 68: doTryCatch
2025-12-16T12:01:13-05:00 67: tryCatchOne
2025-12-16T12:01:13-05:00 66: tryCatchList
2025-12-16T12:01:13-05:00 65: tryCatch
2025-12-16T12:01:13-05:00 64: do
2025-12-16T12:01:13-05:00 63: hybrid_chain
2025-12-16T12:01:13-05:00 62: observe
2025-12-16T12:01:13-05:00 61: observer:output$bottom_right_plot
2025-12-16T12:01:13-05:00 60: contextFunc
2025-12-16T12:01:13-05:00 59: env$runWith
2025-12-16T12:01:13-05:00 58: withCallingHandlers
2025-12-16T12:01:13-05:00 57: domain$wrapSync
2025-12-16T12:01:13-05:00 56: promises::with_promise_domain
2025-12-16T12:01:13-05:00 55: captureStackTraces
2025-12-16T12:01:13-05:00 54: force
2025-12-16T12:01:13-05:00 53: domain$wrapSync
2025-12-16T12:01:13-05:00 52: promises::with_promise_domain
2025-12-16T12:01:13-05:00 51: withReactiveDomain
2025-12-16T12:01:13-05:00 50: domain$wrapSync
2025-12-16T12:01:13-05:00 49: promises::with_promise_domain
2025-12-16T12:01:13-05:00 48: ctx$run
2025-12-16T12:01:13-05:00 47: run
2025-12-16T12:01:13-05:00 46: withCallingHandlers
2025-12-16T12:01:13-05:00 45: domain$wrapSync
2025-12-16T12:01:13-05:00 44: promises::with_promise_domain
2025-12-16T12:01:13-05:00 43: captureStackTraces
2025-12-16T12:01:13-05:00 42: withCallingHandlers
2025-12-16T12:01:13-05:00 41: shinyCallingHandlers
2025-12-16T12:01:13-05:00 40: force
2025-12-16T12:01:13-05:00 39: withVisible
2025-12-16T12:01:13-05:00 38: withCallingHandlers
2025-12-16T12:01:13-05:00 37: domain$wrapSync
2025-12-16T12:01:13-05:00 36: promises::with_promise_domain
2025-12-16T12:01:13-05:00 35: captureStackTraces
2025-12-16T12:01:13-05:00 34: doTryCatch
2025-12-16T12:01:13-05:00 33: tryCatchOne
2025-12-16T12:01:13-05:00 32: tryCatchList
2025-12-16T12:01:13-05:00 31: tryCatch
2025-12-16T12:01:13-05:00 30: do
2025-12-16T12:01:13-05:00 29: hybrid_chain
2025-12-16T12:01:13-05:00 28: flushCallback
2025-12-16T12:01:13-05:00 27: FUN
2025-12-16T12:01:13-05:00 26: lapply
2025-12-16T12:01:13-05:00 25: ctx$executeFlushCallbacks
2025-12-16T12:01:13-05:00 24: .getReactiveEnvironment()$flush
2025-12-16T12:01:13-05:00 23: flushReact
2025-12-16T12:01:13-05:00 22: serviceApp
2025-12-16T12:01:13-05:00 21: ..stacktracefloor..
2025-12-16T12:01:13-05:00 20: withCallingHandlers
2025-12-16T12:01:13-05:00 19: domain$wrapSync
2025-12-16T12:01:13-05:00 18: promises::with_promise_domain
2025-12-16T12:01:13-05:00 17: captureStackTraces
2025-12-16T12:01:13-05:00 16: ..stacktraceoff..
2025-12-16T12:01:13-05:00 15:
2025-12-16T12:01:13-05:00 14: do.call
2025-12-16T12:01:13-05:00 13: fn
2025-12-16T12:01:13-05:00 12: doTryCatch
2025-12-16T12:01:13-05:00 11: tryCatchOne
2025-12-16T12:01:13-05:00 10: tryCatchList
2025-12-16T12:01:13-05:00 9: tryCatch
2025-12-16T12:01:13-05:00 8: retry
2025-12-16T12:01:13-05:00 7: connect$retryingStartServer
2025-12-16T12:01:13-05:00 6: eval
2025-12-16T12:01:13-05:00 5: eval
2025-12-16T12:01:13-05:00 4: eval
2025-12-16T12:01:13-05:00 3: eval
2025-12-16T12:01:13-05:00 2: eval.parent
2025-12-16T12:01:13-05:00 1: local
2025-12-16T12:01:13-05:00 New names:
2025-12-16T12:01:13-05:00 • -> `...1` 2025-12-16T12:01:13-05:00 New names: 2025-12-16T12:01:13-05:00 • -> ...1
2025-12-16T12:01:13-05:00 New names:
2025-12-16T12:01:13-05:00 • -> `...1` 2025-12-16T12:01:13-05:00 New names: 2025-12-16T12:01:13-05:00 • -> ...1
2025-12-16T12:01:15-05:00 New names:
2025-12-16T12:01:15-05:00 • -> `...1` 2025-12-16T12:01:15-05:00 New names: 2025-12-16T12:01:15-05:00 • -> ...1
2025-12-16T12:01:15-05:00 New names:
2025-12-16T12:01:15-05:00 • -> `...1` 2025-12-16T12:01:15-05:00 New names: 2025-12-16T12:01:15-05:00 • -> ...1
2025-12-16T12:01:15-05:00 New names:
2025-12-16T12:01:15-05:00 • -> `...1` 2025-12-16T12:01:15-05:00 New names: 2025-12-16T12:01:15-05:00 • -> ...1

[prubin]

The line "connect$retryingStartServer" has me wondering if maybe the app got disconnected from the R session at some point (but I'm not at all confident that I'm interpreting it correctly). Does the app continue to respond after the plots fail?

[kilonovember]

The app works when deployed exactly as it does on my own computer except for the issue of the two ggplot images rendered with renderPlot().

[prubin]

You might want to add a text output to the UI for error messages and wrap the ggplot calls in tryCatch calls or something similar, writing any errors to the new text output. Hopefully you could get something specific about why the plots are bombing.

[kilonovember]

Google Gemini had me wrapping the renderPlot() calls , the source() calls, the calls to load the plot files, the calls to load the data, and just about every other bit of code that might be relevant in tryCatch calls, all without any change in the output or any of the custom error messages appearing. Thanks for your interest.

[kilonovember]

A second go-round with Google Gemini revealed the fix for this. The problem was deep in how ggplot stores the visualizations it creates. Here is a quote from a much longer conversation with Gemini. I have this conversation stored in an ODT document. If anyone is interested, let me know and I'll provide it. Some of the remarks below may not be perfectly correct. These plots did appear as expected until recently. Nonetheless, the suggested fixes did enable the display of the plots.:

The failure to display your plots on Posit Connect was a classic case of Serialization Decay. While the plots worked on your Mac, they broke when transported to a Linux server because of how R saves complex objects.

Here is a summary of why it failed and how we fixed it.

1. The Core Issues

• Environmental Umbilical Cords: ggplot2 objects don't just store the picture; they store the environment where they were born. When you saved the plot to an RDS file, it included "promises" to find variables like res_vals in your Mac's memory. On the Posit Connect server, those variables didn't exist, causing a crash.
• Lazy Evaluation: Statistical geoms like geom_qq() don't calculate the dots until the very moment the plot is printed. Since the data wasn't "baked" into the file, the server had no numbers to crunch.
• Font and Theme Mismatches: theme_economist() relies on specific system fonts. If the Linux server lacks those fonts, the R process throws an error during the rendering phase, resulting in the generic [object Object] error in the browser.
• Monolithic Global Loading: Loading the full plot objects in the "Universal" section of app.R meant that any serialization error during the readRDS() step would prevent the entire app from initializing correctly.The failure to display your plots on Posit Connect was a classic case of Serialization Decay. While the plots worked on your Mac, they broke when transported to a Linux server because of how R saves complex objects.

Here is a summary of why it failed and how we fixed it.

1. The Core Issues

• Environmental Umbilical Cords: ggplot2 objects don't just store the picture; they store the environment where they were born. When you saved the plot to an RDS file, it included "promises" to find variables like res_vals in your Mac's memory. On the Posit Connect server, those variables didn't exist, causing a crash.
• Lazy Evaluation: Statistical geoms like geom_qq() don't calculate the dots until the very moment the plot is printed. Since the data wasn't "baked" into the file, the server had no numbers to crunch.
• Font and Theme Mismatches: theme_economist() relies on specific system fonts. If the Linux server lacks those fonts, the R process throws an error during the rendering phase, resulting in the generic [object Object] error in the browser.
• Monolithic Global Loading: Loading the full plot objects in the "Universal" section of app.R meant that any serialization error during the readRDS() step would prevent the entire app from initializing correctly.