How reliable is the time field in the FlexMatch event notification messages?

Question

I'm not sure how I didn't notice this before, but apparently each message that gets published to the SNS topic from FlexMatch has two time fields. The first one is a field called Timestamp, which is a part of the whole SNS object that is sent to the lambda function subscribed to the topic receiving gamelift events. I actually refer to this field in another question I had before here. But I didn't realize that the actual message itself inside the SNS object had a field called time. So is the Timestamp field the value of when the message arrived to the SNS topic? While the time field is the true value of when the message was created by FlexMatch? I'm asking because I'm wondering if the time field is a good way to get the correct ordering of the event notifications. This could be very useful for sorting matchmaking ticket information in a DynamoDb table. And when I mention good, I also mean safe. For example, can two events for the same matchmaking ticket/request have the exact same time field? If so, then I am not sure how those events would be differentiated order-wise in a tie-breaker scenario. Here's an example of what the event object looks like when the Lambda function that is subscribed to the topic is invoked,

   "Records": [
        {
            "EventSource": "aws:sns",
            "EventVersion": "1.0",
            "EventSubscriptionArn": "...",
            "Sns": {
                ...
                "Message": "{...}",
                "Timestamp": "2020-05-01T00:45:41.363Z",
                ...
            }
        }
    ]

And that message object in that SNS object could look like this for example,

{
    "version": "0",
    "id": "...",
    "detail-type": "GameLift Matchmaking Event",
    "source": "aws.gamelift",
    "account": "...",
    "time": "2020-05-01T00:45:41.355Z",
    "region": "...",
    "resources": [
        "..."
    ],
    "detail": {
        "tickets": [
            ...
         ],
         ...
    }
}

Hope my question made sense, thank you in advance for any answers!

```
   "Records": [
        {
            "EventSource": "aws:sns",
            "EventVersion": "1.0",
            "EventSubscriptionArn": "...",
            "Sns": {
                ...
                "Message": "{...}",
                "Timestamp": "2020-05-01T00:45:41.363Z",
                ...
            }
        }
    ]
```

And that message object in that SNS object could look like this for example,
```
{
    "version": "0",
    "id": "...",
    "detail-type": "GameLift Matchmaking Event",
    "source": "aws.gamelift",
    "account": "...",
    "time": "2020-05-01T00:45:41.355Z",
    "region": "...",
    "resources": [
        "..."
    ],
    "detail": {
        "tickets": [
            ...
         ],
         ...
    }
}
```

Hope my question made sense, thank you in advance for any answers!

rePost-User-5100160 · Accepted Answer

I asked someone on the GameLift team via email about this topic and thought that it would be good to post his response here:

> Right, there are two pieces of important documentation; SNS notification format [here](https://docs.aws.amazon.com/sns/latest/dg/sns-message-and-json-formats.html), and the Flexmatch message format  [here](https://docs.aws.amazon.com/gamelift/latest/developerguide/match-events.html). The SNS notification contains the entire Flexmatch message in the “Message” field. Each has a timestamp. The SNS message timestamp field is called “Timestamp”, and is the ‘publish’ time when SNS received the message. The message had to be sent before that. And it had to be constructed even before that, so the Flexmatch message contains the “time” field, which should be earlier, when the Flexmatch message was constructed before it was sent.
> 
> The Flexmatch message “time” field is therefore the one to use if comparing times.
> 
> **However...**
> 
> I don’t exactly know if these messages can be generated in parallel for a given ticketID, and frankly I doubt it, but subsequent messages can definitely be generated within a millisecond of each other, meaning that due to the resolution of the timestamp string (which is 1 millisecond), two messages can have the same timestamp on them, for the same ticket ID. Nothing stopping that, and I believe this is often what is happening for the customer.
> 
> For example, I expect it to be  **highly likely**  that AcceptMatchCompleted is generated at almost the exact time that MatchmakingSucceeded is. It could be pretty common for their order to be ambiguous in SNS, and/or the “time” field to be identical in the Flexmatch messages.
> 
> In the case that the tie can only be broken by the logical ordering of the message types.
> 
> This order is:
> 
> MatchmakingSearching
> 
> PotentialMatchCreated
> 
> AcceptMatch (noting that multple AcceptMatch can be generated, and if the time stamps are identical then they cannot be ordered)
> 
> AcceptMatchCompleted
> 
> MatchmakingSucceeded | MatchmakingCancelled | MatchmakingTimedOut |MatchmakingFailed (only one of these ‘final result’ notifications will be generated for any given ticket).
> 
> My advice is only to subscribe to, and only to store the final result notification, if possible, as they are the only actionable ones. The others can be considered noise. If the game is using player acceptance ( *e.g.*  to implement a block list) then it must also subscribe to and respond to PotentialMatchCreated. In the SNS subscription, set up a ‘Subscription filter policy’ to only receive notifications of actionable types.
> 
> If that doesn’t work for the customer, and it really should, then for those notifications whose type implies an order, then the Lambda should test the type of the message already stored and  **ATOMICALLY**  write the newly received one only if there is no later message stored as implied by the message type. This isn’t my preference for performance reasons, but it is a catch-all.

I hope this is okay. If I have to credit the person who said this by name, then I will edit my post to do so. Just wasn't sure if he wanted to be highlighted in this forum post 😛

How reliable is the time field in the FlexMatch event notification messages?

Relevant content