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

Reduce friction for users when reporting ICE #157

Open
1 task
greenhat opened this issue Mar 28, 2024 · 2 comments
Open
1 task

Reduce friction for users when reporting ICE #157

greenhat opened this issue Mar 28, 2024 · 2 comments
Labels
feature New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@greenhat
Copy link
Contributor

greenhat commented Mar 28, 2024

When ICE happens, the cargo extension could gather all the context (source files, dependencies, Cargo.toml, etc.) and after asking the user's permission, generate a file(output?) that would be posted as an issue in this repo.
Alternatively, the cargo extension could interactively ask the user's permission and create the issue (using gh, HTTP API, etc.) and upload all the context info (see above).

Tasks

@greenhat greenhat added this to the Alpha milestone Mar 28, 2024
@bitwalker
Copy link
Contributor

We almost certainly can't include source files automatically, and would need to be very careful about any data we do collect, even if we ask permission to create an issue. If the project is proprietary, or otherwise covered by some sensitive contractual agreement (like an NDA), uploading those kind of artifacts could get someone in deep trouble. But even setting that aside, in general, people can be very touchy about things like that.

Fundamentally, we'll need cooperation from the person who reported the error, so I think we can rely on them either providing us the source (and other necessary details), or an equivalent reproducer, upon request. If they can't/won't, then if we are unable to proceed without that, then we just close the issue until we encounter it again but with additional context/data we need.

What I think we definitely can do by default, are necessary to troubleshoot most issues, and are at least provided currently by human_panic are:

  • The platform on which the program is being compiled (i.e. are they running the compiler on macOS, if so, what version, etc.)
  • The full version (including git hash) of the compiler that produced the error
  • The target type (e.g. "core" Miden, or the rollup)
  • Any flags passed to the compiler or higher-level tools, stripped of any potentially sensitive information (not sure we have any of those currently anyway, but wan't to be explicit about that point)
  • The full backtrace of the panic/error that occurred
  • Any warning/error diagnostics produced during that invocation (if we captured them) (NOTE: This isn't provided by human_panic, but is something I think would be useful)

Anything above and beyond that will require cooperation by the user reporting the error (i.e. providing us with the source code, or an equivalent reproducer; dependencies and their versions, any other configuration or necessary context).

I think we should also summarize what we're sending when reporting an issue, and where that payload is, so that they can review it and upload it by hand if they so choose.

@bitwalker bitwalker added feature New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Mar 28, 2024
@greenhat
Copy link
Contributor Author

I updated the description to ask the user's permission for including the sources. For an unknown reason, I did not spell it out, although I always had that in mind.
I agree that it might be a big ask and should not be the default behavior.

@bitwalker bitwalker removed this from the Alpha milestone May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants