Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittent Docs display and docs-to-html output failures #5506

Open
rlmark opened this issue Dec 13, 2024 · 1 comment
Open

Intermittent Docs display and docs-to-html output failures #5506

rlmark opened this issue Dec 13, 2024 · 1 comment
Labels

Comments

@rlmark
Copy link
Contributor

rlmark commented Dec 13, 2024

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:

@rlmark rlmark added the bug label Dec 13, 2024
@ceedubs
Copy link
Contributor

ceedubs commented Jan 22, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants