unison icon indicating copy to clipboard operation
unison copied to clipboard

Intermittent Docs `display` and `docs-to-html` output failures

Open rlmark opened this issue 1 year ago • 1 comments

Describe and demonstrate the bug

This failure is intermittent, so reproducibility is a bit of a challenge at the moment. Some Unison Doc terms are not able to be rendered by either the display or doc-to-html commands, but with time or retries, they eventually succeed.

If the failure does happen, it's typically after editing a large document in the website. Upon saving, you might run a check with display to try to view the output. The display will first fail with the following error:

@unison/website/main> display atAGlance

  attempted to use sandboxed operation: IO.stdHandle

If that happens, and you run the display command again, the Doc term is able to be rendered:

@unison/website/main> display atAGlance

  attempted to use sandboxed operation: IO.stdHandle

@unison/website/main> display atAGlance

  # 👀 Unison at a glance
  [...]

I do not know if the display command is linked to the doc-to-html command, but the effect for readers of the Unison website is that some terms end up with html that looks like this:

Screenshot 2024-12-13 at 11 54 53 AM

In circumstances where these html pages are produced instead of their regular content, my workaround has been to display the underlying Doc term until the "attempted sandboxed operation" message goes away, and then a subsequent docs-to-html command has thus far always worked.

Environment (please complete the following information):

  • UCM version: release/0.5.29 (built on 2024-12-02)
  • OS/Architecture: macOS 14.5, M1 chip

Additional context The specific doc terms that I have experienced this happening with are:

  • https://share.unison-lang.org/@unison/website/code/main/latest/terms/docs/atAGlance
  • https://share.unison-lang.org/@unison/website/code/main/latest/terms/docs/tour
  • https://share.unison-lang.org/@unison/website/code/main/latest/terms/docs/fundamentals/abilities/errorHandling

rlmark avatar Dec 13 '24 21:12 rlmark

I just ran into this in the cloud client as well.

Since it works after the first time, it seems like a result might be getting cached. But running debug.clear-cache doesn't make it fail again. This smells a bit like #4685 in that you hit a sandbox error but then it goes away after other actions.

Image

ceedubs avatar Jan 22 '25 18:01 ceedubs