Wrong events for MediaLive state changes

Question

We have a lambda configured to be triggered by MediaLive Channel state events:
```json
{
  "detail-type": [
    "MediaLive Channel State Change"
  ],
  "source": [
    "aws.medialive"
  ]
}
```
MediaLive channels are standard and have 2 pipelines.
When channel is stopped and started again, we usually recieve STARTING and RUNNING state change events like

'detail': {'pipelines_running_count': 2, 'state': 'STARTING', 'pipeline': '0', 'channel_arn': '...', 'message': 'Pipeline started for channel'}}

'detail': {'pipelines_running_count': 2, 'state': 'RUNNING', 'pipeline': '1', 'channel_arn': '...', 'message': 'Pipeline started for channel'}}

But sometimes instead of RUNNING event, we get only second STARTING event like

'detail': {'pipelines_running_count': 2, 'state': 'STARTING', 'pipeline': '1', 'channel_arn': '...', 'message': 'Pipeline started for channel'}}

Is it intended behavior or a bug in AWS MediaLive? If we cannot rely on state changes, what is the best way to handle such situation?

Answer

This could be because Media Live is best effort delivery as per https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-list.html. In this case, you have few options :

1/ Publish events of your own in parallel to Media Live events. This way you get your own events as backup in case Media Live events do not arrive.

2/ Create a support request for MediaLive to offer better delivery attempt guarantees.

3/ Call their front-end repetitively to detect state changes :(

Answer

The second starting event could be due to the platform taking longer to actually start the instance and spin up the Channel.  Since each pipeline occupies its own EC2 instance, one may finish promptly while the other waits for some pre-requisite to complete. So you may occasional  duplicate starting messages.

Baldawar is correct, the best way to know the readiness of a Channel is to actually poll it.  Lambda functions work well for this as most MediaLive channels start in well under 10 minutes,  and Lambda functions have a fifteen minute life span.  There should always be a BatchStart or similar API event from which you could trigger a monitoring Lambda. You could go further and have the Lambda start a backup channel in the event that the primary one doesn't become ready after XX minutes.

Wrong events for MediaLive state changes

Relevanter Inhalt