recording.resumed webhooks do not contain a timestamp for when the action occurred. This causes a few issues:
- We cannot use these events to accurately calculate a timeline of these events due to network delays, etc.
- If these events are received out of order (which we have observed!), then it’s impossible for us to maintain a correct state machine for the recording i.e. when we receive resumed before paused, we appear to be stuck in the paused state indefinitely.
Any chance that this could be added to the roadmap?