StartMatchBackfill never returns

Hi everyone,

I am currently implementing Backfill for our game and ran into a problem trying to get Backfill to work. I am using UE4.21.2 and AWS GameLift SDK Version 3.30. I trying to call StartMatchBackfill() from a Dedicated Server running on a fleet. Also I am using the UE AWS Gamelift Plugin.

The problem is that the process never returns from the call to Aws::GameLift::Server::StartMatchBackfill() and becomes unresponsive. (Meaning clients time out and the CPU is at 0% constantly. No more log output is generated after that call.)

I can’t really debug anything for this call, because I can’t remote debug to the fleet instance.

Anyone have any Idea what is going on? I should at least get an outcome and not have the process stop in its tracks and drop all players.

My request seems to be correctly filled out. Here is an example:

TicketId: empty. (I want AWS to generate one for me, just like in StartMatchmaking())

MatchmakingConfigArn: arn:aws:gamelift:us-west-2:614596651069:matchmakingconfiguration/

GameSessionArn: arn:aws:gamelift:eu-central-1::gamesession/fleet-a5bac22d-e5ce-4f11-a366-07115942cd2d/f094583b-99c4-4eaa-afa9-1cc89ddcdbfa

There also is one player in the request, including latency data for just the region the game session is running in. (eu-central-1)

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:aws:gamelift:us-east-1::gamesession/fleet-38b65aba-93f8-4031-a739-2c53b0108e8e/702f4f0d-0e50-421f-a8da-bbea6f8bdbc9
MatchmakingConfigurationArn=arn:aws:gamelift:us-east-1:751564710173:matchmakingconfiguration/d-UploadFixed
Players=3

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

1 Like

@Stefan_BA

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.