[Question] Automated submission

[polarathene]

Could this crate at a later date optionally allow for sending the report on behalf of the user if they allow it rather than manual submission from the user? Or would that be the responsibility of another crate that builds off this one?

[epage]

This kind of stuff is nice but a lot of details to work through

• privacy
• where to upload
• how to analyze

I wonder if something like breakpad can be used. Ideally a company would offer hosting travis-style.

[skade]

Also to note: you are currently in a panicking program. Any panic in the submission process will abort.

[yoshuawuyts]

I wonder what the lowest effort approach to this would be? I'm thinking exposing a hook of sorts might make the most sense.

e.g. have a method that on error calls some callback, and passes it a PathBuf to the location the file is stored. Then the package owners get to decide how to process that.

Probably would need to remove the "we take your privacy seriously, and don't do automated collection" bit for that method though.

Example

human_panic::set_hook!(|path: PathBuf| {
  // handle path here, return Result<(), Error>
})

[skade]

I think the best approach would be what most serious programs do: do your error handling, open a separate crash-handling program. Give the user of the library the chance to choose the program, no more.

Hooks within hooks within hooks doesn't seem like a good solution.

[ghost]

Hi folks, I have a suggestion for easy, user-friendly report submission while preserving privacy:

Github, and Gitlab-but-it's-undocumented, support URL-encoded pre-filled fields for opening issues.

For Github, the documentation is here.

For Gitlab, it appears that fields may be set for an issue using URL parameters of the form issue[field_name]; indeed, the default URL for making new issues includes two empty fields in this format:

https://gitlab.com/<user-or-org>/<repository>/issues/new?issue[assignee_id]=&issue[milestone_id]=

I tested this with the fields title and description and found them to work. The fields correspond inexactly to the POST API fields.

So, how about if human-panic could optionally offer pre-filled issues containing traceback information that were clickable by users? That would preserve privacy, because it's an opt-in decision to report, while also letting the developer choose what was worth adding to the report?

[epage]

@cathalgarvey That is a nice approach. I wondered about auto-creating issues but that could inundate projects. Pre-filled means it still requires human action.

Speaking of inundating projects, ideally, github would take whats being typed in an issue and suggest similar issues to help people avoid filing dups.

[follower]

An alternate approach with its own trade-offs/failure states[0] would be to (on next execution) detect if a/the previous execution generated an panic & offer to submit the report (or output a message indicating how to do so, e.g. via a command line flag such as --submit-last-panic-report which could include whatever level of active confirmation/consent was required).

While it's a different context, this pattern of "act on next run" has previously been used in GUI applications to handle e.g. document recovery and/or error reporting.

Primarily mentioning this to highlight that "reporting/submitting at the time of panic" is not the only point in time that an approach can use.

---

[0] e.g. non-interactive execution; potential impact on start-up time; etc.