Decoupling Dataset Object from ErrorPlugin Downstream Effects ?

[hujambo-dunia]

On the backend, in order to allow for greater bug report capturing, is there any objection to decoupling the Dataset Object so that a Dataset Object is not required on the Bug Report?

For example, we can have one Bug Report (instead of multiple Bug Reports) for when a Tool fails but doesn't yet contain a Dataset? Another way to ask is "Is it even possible to decouple/separate the ErrorPlugin class from the Dataset Object by only changing the 5-8 methods for this purpose (and without changing the database and without downstream effects)?" Currently, Bug Report for Dataset is tightly coupled with the Dataset Object and the Tool Object. However, we have errors when there is no Dataset Object as in this issue here but still generates an error. Furthermore, we might have future objects lacking a Dataset Object which we want error reporting.

In my opinion, all error logging should be modular and decoupled from other objects. If you get an error on a Tool, you get the Tool information - if there happens to be a Dataset involved, that comes through also but isn't required. That way, you can put the error logging on any type Object we have currently or will have.

For a visual reference, PR #19508 (which addresses #17560) looks something like this. If decoupling of Dataset Object from ErrorPlugin{} class occurred that would mean backend methods below # 1-6 (below) would be modfieid so that Dataset Object was not a requirement.

[mvdbeek]

To summarize the discussion from the dev meeting: yes, it would be good to report on jobs instead of datasets. The API is already centered around the job id but requires a mandatory dataset_id. That's not necessary, and some failed jobs may not even include discovered datasets. Changing the templates to make the dataset id optional is a definitely a good change.

I don't think we need a component for submitting submission errors, instead these should all be gracefully handled, as they are actual Galaxy bugs, and not something an admin or support personnel can understand or help with (unless they happen to be intimately familiar with the tool submission API, I would say that's not common). We do see these in our bug reporting platform (though of course you can also just look at the logs), and we fix them as we encounter them, here are some recent examples: #18858, #19483, #19480 etc. #18023 fixed the particular issue you've cited, but you mentioned you can still reproduce this, if you can it would be good to open a new issue for that.

The final thing to do is that we should attempt to link up the sentry id to give users a possibility to come back to us with an id. We used to do this using the sentry WSGI middleware, but I don't think this still works.

[hujambo-dunia]

Thanks for the sample links @mvdbeek. I do agree that Sentry is good for US team's internal use on UseGalaxy.org. However, I question if our Admin users are getting targeted error metrics from their Galaxy instance in the event that they do not want to manage/pay for the 3rd party metrics tracker (Sentry). Those Admins would be relying on Galaxy's default error plugin (ErrorPlugin{}). Granted, a "Tool Transcript" may not count as truly "targeted". For UseGalaxy.org, I'm fine with @dannon's suggestion to (1) update wording and (2) possibly display the backlink to Sentry (assuming Sentry logged it) so the user knows it's being tracked and close out this open issue. So I will implement as suggested.

In regard to this particular bug which launched this discussion, it is on production tested at about 3:30 PM US-ET on usegalaxy.org (it was still in the codebase as of about 2 weeks ago, but I did not pull the non-released dev branch today). Here are the steps (and GIF) to reproduce:

1. Download and unzip these 24 files of sample data. Then, download this Rules json file.
2. On Galaxy, open the "Apply rules" tool.
3. On Galaxy in the Activity Bar, click Upload icon-button
4. Click "Collection" tab
5. Below steps need to be completed before all files are processed in the History panel
6. Drag-and-drop the 24 files on the Upload-Target field form
7. Click "Start" (do not close upload modal)
8. Wait until all files turned to 100% / green, click "Build" button. The History panel will show the individual files being processed (24 files in the History panel).
9. Should see a different modal underneath. Name the collection and click the "Create Collection" button.
10. In the History panel at the top, click the "<<" arrow to go back to viewing the Collection Name (1 item in the History panel).
11. From the History panel, drag-and-drop the Collection Name to the center panel ("Apply rules") "Input Collection" field.
12. In the center panel,click the "Edit" icon-button.
13. In the "Apply rules" modal, click the wrench-icon (next to "Rules").
14. Copy and paste the JSON file content into the Textarea box. Click "Apply". Click "Save".
15. In the center panel, click the "Run" button.
16. Error modal pop-up should appear. Click "Ok" to close.

ecpc.zip

Rules_Content.txt

[mvdbeek]

it is on production tested at about 3:30 PM US-ET

that's yesterday, on usegalaxy.org ?

When I follow the instructions I also get the following (unnecessary) modal, which I haven't spotted in your gif, so I assume the gif is from an older date ?

Here's what happens when you're fast enough (also note that you can only override this if you drag the collection in):

That message could be improved (this would absolutely be a worthwhile project, the API response is structured so you could mount a nice little component that explains this further), but the rule builder is a feature for power users that probably know what the auto extension is, and who know that you can override the backend selection with drag-and-drop, so I'm gonna say they understand that they either need to set the extension on upload or wait until the extension is determined if they see that message.

Those Admins would be relying on Galaxy's default error plugin

Assuming what you want to implement is done, what would that support personnel do with the API request (which is the only piece of information that could be reported) ?

[hujambo-dunia]

@mvdbeek Is this PR along the lines of what you had in mind?

#19562

[hujambo-dunia]

@mvdbeek Just realized didn't respond to your question.

Assuming what you want to implement is done, what would that support personnel do with the API request (which is the only piece of information that could be reported) ?

The support personnel would manage this in the same way existing bug reports are processed (email received, email evaluated for priority, email response routed to dev/admins if needed).

[hujambo-dunia]

@mvdbeek In regards to "mount a nice little component that explains this further", this could also just be ported directly into the existing GalaxyWizard, right? The error isn't so common to cause rate-limit issues. (And for Admin users, if the user had no OpenAI api-key saved, then there would essentially be no change - no additional explanation would be provided.)

[hujambo-dunia]

That is correct, @mvdbeek - the GIF is from an older run (March 2024) and I was able to replicate the bug from yesterday (February 2025).

That message could be improved (this would absolutely be a worthwhile project, the API response is structured so you could mount a nice little component that explains this further), but the rule builder is a feature for power users that probably know what the auto extension is, and who know that you can override the backend selection with drag-and-drop, so I'm gonna say they understand that they either need to set the extension on upload or wait until the extension is determined if they see that message.

Very interesting - I am glad to hear that this specific bug is just an extension assignment issue. I will look at straightforward messaging solution to close out the ticket.