Fix race condition with certain drives and certain disks

[hey-look-a-throwaway]

Description

Noticed that with an external drive (an external LG SP80NB80) and certain disks (maddening!), there would be a race condition with the drive being ready. Adding a few retries and moving the abort check before we create the Job() fixed it on my machine.

Fri Apr 19 01:38:56 UTC 2024 Entering docker wrapper
Fri Apr 19 01:38:56 UTC 2024 [ARM] Starting ARM for DVD on sr1
[2024-04-19 01:38:57,689] INFO ARM: main.<module> Drive appears to be empty or is not ready.  Exiting ARM.

If I added the retries where the old "Drive appears to be empty" check was, it would bail at ARM is trying to write a job to the empty.log, or NAS**.log, so I moved it before.

Anyway, not sure if this is the appropriate place to put this (maybe the issue is with that wrapper?), but it fixed it for me.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

It didn't work with some disks (seemed like dual layer ones?), and it does now

• Docker

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have tested that my fix is effective or that my feature works

Changelog:

• Add retries for drive being ready before creating the Job object
• Move the final drive readyness check as well so that it aborts if it never gets ready

Logs

Attach logs from successful test runs here

Fri Apr 19 02:29:44 UTC 2024 Entering docker wrapper
Fri Apr 19 02:29:44 UTC 2024 [ARM] Starting ARM for DVD on sr1
[2024-04-19 02:29:44,897] INFO ARM: main.<module> Drive appears to be empty or is not ready.  Waiting 1s
[2024-04-19 02:29:45,923] INFO ARM: main.<module> Drive appears to be empty or is not ready.  Waiting 1s

[microtechno9000]

Nice fix
can you provide a log of the error pre fix for comparison

[hey-look-a-throwaway]

The first code snippet is the befeore log

Fri Apr 19 01:38:56 UTC 2024 Entering docker wrapper
Fri Apr 19 01:38:56 UTC 2024 [ARM] Starting ARM for DVD on sr1
[2024-04-19 01:38:57,689] INFO ARM: main.<module> Drive appears to be empty or is not ready.  Exiting ARM.

[microtechno9000]

Cheers
Had in my head the code was in a loop, not failing due to states.

Good fix, only suggestion would be to amend the INFO statement to state something like [attempt x of n], otherwise users may see the line multiple times in the log and think there is another issue. Once you have added that, good to approve.

[shitwolfymakes]

Cheers Had in my head the code was in a loop, not failing due to states.

Good fix, only suggestion would be to amend the INFO statement to state something like [attempt x of n], otherwise users may see the line multiple times in the log and think there is another issue. Once you have added that, good to approve.

Seconding this, better logging will be great

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[microtechno9000]

good fix, added in the x of y run numbers to provide more information to the end user