Alan King

I don't think you need to run them again. It would just be good to note which ones fail in the future (particularly if they are failing repeatedly) so that...

Possibly similar to https://github.com/irods/irods/issues/7389, although it seems I only observed the failure on Debian...

Linking to https://github.com/irods/irods/issues/7521 as well. Something funny about this test suite.

As part of this effort, we also need to make `itrim` more picky about the kinds of inputs it accepts for targeting replicas. The following should be accepted: - `LEAF_RESOURCE_NAME_KW`...

After some discussion, we have determined that simply removing the `-N` option may lead to surprising results as the default `numCopies` must be changed to 1 replica. The surgical/rigid approach...

After discussing again... Removal of `-N` is such a fundamental change to `itrim` and the API as we know them that we will do this in 5.0. Changing the milestone.

Feels similar to https://github.com/irods/irods/issues/6504. This test actually asserts that `CAT_SQL_ERR` occurs: https://github.com/irods/irods/blob/344f9c70a97d5adfe50bd23e65bbe9547cf78e40/scripts/irods/test/test_imeta_error_handling.py#L79-L89 The `CAT_SQL_ERR` only occurs on certain unixODBC versions (

Oh, I got it backwards. It's versions > 2.3.5 that return `CAT_SQL_ERR`, so that does indeed indicate that we may have been leaning on a bug here.

If they are launched truly in parallel, the database race condition described here still applies until we fix it: https://github.com/irods/irods/issues/5742#issuecomment-905439542

Also seems potentially related to https://github.com/irods/irods/issues/7389 and #7458. Just linking these together for posterity in case it proves useful