Warning
This document is for an in-development version of Galaxy. You can alternatively view this page in the latest release if it exists or view the top of the latest release's documentation.
Bug Reports
In 17.09, bug reports were refactored to a plugin-type infrastructure. This
gives the administrator more control over how and when bug reports are
generated. In the past, email reports would be generated when the user clicks
the button and only then. Sentry reports would be generated for every failing
tool, as soon as the tool failed. This disparate behaviour was unified under a
single configuration file, config/error_report.yml.sample
.
Let’s look at that briefly:
- type: email
verbose: true
user_submission: true
- type: sentry
user_submission: false
The actual configuration file contains more documentation which has been stripped out here for the sake of brevity. As you can see, there are a couple of different plugins that already exist. Additionally, there are some options that are common to all plugins:
user_submission
When true, this action is triggered only when the user is on the job error page and clicks “submit bug report”.
When false, this action is triggered any time a job errors, without user involvement
verbose
When
user_submission: true
, andverbose: true
, this indicates that a message is to be displayed to the end user. For example, the email plugin will inform the user that an email has been sent. Similarly, the JSON plugin will inform the user that a file has been written to a specific directory.
Email
This is the classic bug-report mechanism that we are all familiar with. It generates an email to the admin and the submitting user containing detailed information about the job and links to the precise locations within Galaxy.
As a plugin, nothing has changed to this functionality, though future updates
may add features. It currently takes all of its configuration from your
$GALAXY/config/galaxy.yml
, e.g. the variables error_email_to
and
email_from
.
JSON
This is a demo-plugin that writes the contents of the error report to a file in your temp directory. This just serves as a full-featured reference implementation that others can use to build their own bug reporting plugins.
When user_submission: true
and verbose: true
, the plugin will inform the
user that a report has been written to /tmp/reports/<number>
.
Sentry
This refactors the existing on-failure submit-to-sentry behaviour into a bug reporting plugin. Now, for example, you are able to disable the automatic submission to sentry and only run that whenever the user reports it.
When user_submission: true
and verbose: true
, the plugin will inform the
user with Submitted bug report to Sentry. Your guru meditation number is
dc907d44ce294f78b267a56f68e5cd1a
, using the same phrasing that is common to
users from Galaxy internal server errors.
InfluxDB
This sends data directly to an InfluxDB server that you have available. If you
wish to use this plugin you will first need to pip install influxdb
in
Galaxy’s Python virtual environment.
This plugin will send a value of 1
every time an error occurs, tagged with
important information such as:
handler
tool_id
tool_version
exit_code
This allows you to visualize the rate of bug reports (group by time(30m)
,
adjust as needed for how many error reports you see) in conjunction with any
other data you’re already tracking in InfluxDB/Grafana. This setup allows
answering questions such as “did the change I make decrease the number of tool
failures on average”
GitHub
This plugin submits user bug reports to a GitHub repository of your choice. It uses the HTML formatter from the email bug reporter.
Before submitting a bug report, the plugin will search for any open issues with a matching title. If there are no matching issues, it opens a new issue, otherwise, it makes a comment on the existing issue. This provides some measure of de-duplication.
Issues will be tagged with the tool and version.