While checking another ticket the error is noticed on https://folio-testing-sprint-cs00000int.ci.folio.org/ environment

Verified by reviewing screenshots provided by Vadym. Works as expected

Dev tested on consortium rancher via disabling some inventory and consortia modules:

Hi , I would like to add some additional context here.
There is a list of hardcoded ERROR_STATUSES as per now

Most popular as per me:

Also module names which were harcoded:

Mikita proposed check library, which also contains most popular codes, and we can avoid hardcoding them on our side, but will have +1 dependency.

cc

While yes, the messages are different from one another in their meaning, there’s nothing that a user can do to affect a ‘bad request’ is there? - and to a developer “418” is just as good as saying “418: I’m a teapot” (yes, that is the actual HTTP error message!) I’m all for pruning that list if that’s really the best we can provide in this scenario - but seeing some of the screenshots around this bug and varying levels of detail for the error message - from the users’s perspective - what happens next in the workflow when such errors are encountered? Is there a retry mechanism for failed records? When it comes to the implementation details in the applicable PR, holding static lists of data that get very little usage - and other static lists of data (backend modules connected to the platform) that are technically unknown/out of scope to this module, it begs the question if there is any other information that Bulk Edit itself holds and can easily present that might be more useful in helping the user to work around the error and move forward. This seems like it would be applicable even when the backend does return an error message and the UI isn’t having to account for the shortcoming of the backend.