fix(recording): Handle the problem gracefully when the recording can …

[nickvergessen]

…not be uploaded

☑️ Resolves

• Fix Recording upload failed due to missing user #9905

🛠️ API Checklist

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not possible
• 📘 API documentation in docs/ has been updated or is not required
• 🔖 Capability is added or not needed

[nickvergessen]

/backport to stable29

[danxuliu]

Tested and works 👍

Note that if the recording is larger than post_max_size currently there will be three notifications, because the recording server retries the request three times. If upload_max_filesizeis exceeded, on the other hand, there will be a single notification, even if the request is retried three times anyway.

The reason is that with the changes in this pull request the owner is stored in the app config when starting the recording, and deleted when storing it. If the owner is not received in the store request the store fails, and the owner is got from the app config and a notification is sent to that user. However, if the owner is not found in the app config (because the recording was already stored) no notification will be sent.

In the case of post_max_size the store always fails, so the owner is not cleared from the app config, and the notification is always sent. With upload_max_filesize the store is started, so the owner is deleted, but it later fails. When the new requests are sent it seems that they are now empty (most likely a bug in how the recording server handles the streaming upload in retries), so the owner is not given in the store request and the store fails, but as the owner was already deleted from the app config no notification is sent.

It would make sense to also delete the owner from the app config as soon as a notification is sent, but that might have other unexpected behaviours, so something for a follow up.