StartMatchBackfill never returns

Hi, we've had a few posts around issues with StartMatchBackfill being called from the Server SDK with empty/null ticket IDs. For now, please create unique ticket IDs on your end to get unblocked right away. I'm working on a fix for empty/null ticket IDs from the Server SDK on our end and will update the forums when we have that fix available in all regions. Sorry for the inconvenience! If you're still seeing issues and not receiving an outcome after generating unique ticket IDs, update the post and we can dig deeper to see if there's anything else happening.

The GameLift Server SDK should now be able to call StartMatchBackfill() without needing to specify a ticketId in all regions. Please let us know if you still have issues with blank ticketIds in the future!

I'm just now debugging an issue where StartMatchBackfill is blocking and never returning.

We're also on version 3.30, Unreal 4.20 so we can't easily upgrade to the latest SDK.

However, in our case we ARE setting a backfill ticket ID, of the format: "b-<sessionID>-<incrementing number >"

Example: BackfillTicketIDToSend=b-702f4f0d-0e50-421f-a8da-bbea6f8bdbc9-0 SessionID=arn:****** MatchmakingConfigurationArn=arn:****** Players=3

Are there other circumstances that could be triggering the blocking behavior? Thanks!

@REDACTEDUSER

I will ping the GameLift team on this.

Firstly, how are you allocating your backfill request? If you are using the stack, then you may want to move to dynamically allocated memory due to the size of this request (depending on how much data you are packing in there).

Obviously it shouldn't hang but it can lead to data mangling if your request is too large.

Secondly, do you see any matchmaking tickets created for your request?

Thirdly, try taking your backfill request to the cli first. Ensure that all your fields are correctly formatted and you can make the request via the cli. I vaguely recall there being some issues in the past where StartMatchBackfill would fail on the server sdk as it didn't handle errors very well.

Sorry about the delayed reply on this. I took a look at our system logs for the time of your failed request and see the problem. It looks like you are constructing some of the AttributeValues associated with this request as AttributeValue() (at a minimum, "ranking" looked to be like this). We really shouldn't allow that as it creates an untyped AttributeValue which will always return this error. Instead, be sure that you are always constructing these with the desired type, e.g. AttributeValue(3.0), or Attribute("DesiredMapName"). We also should have better error messages for these cases and have logged a bug to capture this.

In the meantime, Pip's advice is solid if you encounter issues in this area -- try the request in the CLI first as the error messaging is more robust there and should help you avoid some trip-ups like this.

Great thank you this is very helpful. The hang did indeed go away when we explicitly set the ranking attribute in our request.

It does seem to imply though that something within the Unreal plugin was setting the null ranking value, ex AttributeValue(). From our perspective the interface for attributes is to pass in a map of name/value pairs on the FPlayer struct: TMap<FString, FAttributeValue> m_playerAttributes;

I haven't debugged, but my first guess is that FAttributeValue type was set to None. But those were properties sent to us by the flexmatch OnUpdateGameSession, so there may be a bug there if it's not setting the type.

In any case, thank you for the help. We'll know what to do in the future if we trigger this again.