RecordingFailedException is overrided from SPACE_FULL to INSUFFICIENT_RESOURCES for FAILED_STATE.
UseCase: To track the recording state passes through IN_PROGRESS_WITH_ERROR_STATE (due to SPACE_FULL) and then FAILED_STATE (due to SPACE_FULL).
For the above usecase, I have created 15MB of MSV & schedules a recording of 5 min, which will fill the MSV completely. When this recording goes to IN_PROGRESS_WITH_ERROR_STATE (due to SPACE_FULL), I am scheduling one more recording of 1 min and waiting for the second recording to be over, so that any extra space in the MSV even after the first recording fills, will be completely filled by the second recording.
Now, I am scheduling the third recording of 1 min and tracking for its states for the above use case.
Note That, all the three recordings I am scheduling is on the same service.
Now, what happens is the Third recording is going to IN_PROGRESS_WITH_ERROR_STATE due to SPACE_FULL & recording is transition to IStateSuspendedTunerUnavailable after releasing its TimeShiftWindowClient. The first recording was still not over, so from IN_PROGRESS_WITH_ERROR_STATE , it started again & trying to see if any space is available on the MSV to record. On failing to freed up the space, this recording again goes to the IN_PROGRESS_WITH_ERROR_STATE & release all its resources. Due to this, NI Offer is raised and listen by the third recording. The third recording is now acquiring the NI to start the recording before checking for free space. While it acquiring the NI, stop spec is getting fired since 1 min of recording duration over.
This stop spec was handle by IStateSuspendedTunerUnavailable which is transiting the third recording to FAILED_STATE and overrided the FailedException to INSUFFICIENT_RESOURCES. This I observed few times when running the RI Simulator on Windows.
I certainly agree that this might be an edge case for the threading issue. But i am able to reproduce it more frequently with default log.
If I am enabling the DEBUG logs, I am not able to reproduce the issue.