We decided to apply a minimum "time window" before canceling any job request.
Before this threshold is achieved, we should not cancel the request. Instead, if necessary, we should be delaying/retrying them. The exact details need to be defined.
The delay should be applied per tape file. We can take advantage of different tape copies to by pass delays on some tapes.
TODO: Write document proposing new behaviour/approach.

We decided to change the approach to this problem. Instead of making use of the IS_ACCESSIBLE column (needs to be reverted on the git repo, before any new release), we will simply remove all the retry logic from the repack retrieve requests. This will mean that the operators can quickly get a list of all tape files that failed to retrieve (files that remain on the tape after the repack). Then, they can manually issue a new repack, mount on a different tape drive, or simply handle the tape as they desire.
Vlado will write a document on how the retry logic should be done for repacking (failed segments), taking into account the discussion during this meeting.
Catalogue commits are to be reverted from main and put back into a separate branch. The commit that adds IS_ACCESSIBLE should be removed from this branch.

We won't be discussing this for now. Once we are more familiar with operating the new REPACKING behaviours - after new year's eve - we will revisit this topic.

For now, operations will filter out these messages, since they are not a problem.
They will permanently be removed (or have their priority reduced) in a future commit.

The only thing to do on the dev side is to increase the STALL constant. The rest will be handled by operations.