[24.2] Don't fail startup on conflicting data table definition

[mvdbeek]

While I'm all for failing hard on configuration issues, this one is almost unpredictable, as rebooting a galaxy instance will fail if being unlucky enough to install the wrong combination of tools with data tables. And it won't fail during installation, but at any point a restart is necessary, making it not obvious what caused this and when to expect this.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

Test failures unrelated and result from the branch switch 😆

[jmchilton]

This feels like it will cause the problem to happen more and what happens when these tools are used? It seems like the right course is to force admins to fix the tool data tables - not that I have any clue how to do that. So I think I'm an approve because I don't know how to actually fix the problem and -0 at the same time.

[mvdbeek]

This feels like it will cause the problem to happen more and what happens when these tools are used?

I won't let this slip by in sentry, and I think the .eu team also has an eye on it. We should have the tool shed refuse this too ...

[mvdbeek]

You know what - there should be a singular source of truth for each loc file. When things like #19855 happen - we only install tools that match the loc definition.

that is a good idea. the tool shed should probably also refuse upload ... actually I kind of think it used to ?

[mvdbeek]

I'll see if I can do that

[jmchilton]

actually I kind of think it used to ?

I don't think I removed code that did this. In my head this was always an unaddressed problem. But my memory has already been proven fairly wrong on that other issue earlier in the week.

[mvdbeek]

yeah, it's not because of recent code, we haven't updated MTS in a long time. But I know I touched related code a couple of years ago that could have potentially broken the checks

[martenson]

We should have the tool shed refuse this too ...

agreed, with instances moving to autoupdate enforcing consistency at TS makes sense to me