Request context not propagated to allocator in allocation service

[Reasonably]

What happened:

When operating many GameServers in a single cluster, allocation latency can occur. In this situation, if the client sending the allocation request terminates due to a timeout, the agones-allocator does not stop the allocation process. Since requests are put into a queue and processed, once timeouts start piling up, the situation gets worse - the allocator continues processing requests that clients have already given up on, causing a cascading effect.

What you expected to happen:

When a client cancels an allocation request (due to timeout or explicit cancellation):

• The request should not be added to the queue, OR
• If already in the queue, the allocation logic should be skipped when processing it

How to reproduce it (as minimally and precisely as possible):

1. Deploy Agones with many GameServers (enough to cause allocation latency)
2. Send multiple allocation requests with short timeouts
3. Observe that the allocator continues processing requests even after clients have timed out
4. Notice that timed-out requests accumulate in the queue, worsening the overall latency

Anything else we need to know?:

Root cause: In cmd/allocator/main.go, the gRPC request context is not passed to the allocator in the standard (non-ProcessorAllocator) path. The workerCtx (server lifecycle context) is captured in a closure instead of using the per-request context.

  // line 521-523 in newServiceHandler
  allocationCallback: func(gsa *allocationv1.GameServerAllocation) (k8sruntime.Object, error) {
      return allocator.Allocate(ctx, gsa)  // ctx here is workerCtx, not request ctx
  },

  // line 755 in Allocate method
  resultObj, err := h.allocationCallback(gsa)  // request ctx is not passed

Note: The ProcessorAllocator path correctly passes the request context (line 742), but the standard path does not.

Environment:

• Agones version: 1.45.0 (but it's the same as main also)
• Kubernetes version (use kubectl version): 1.31
• Cloud provider or hardware configuration:
• Install method (yaml/helm):
• Troubleshooting guide log(s):
• Others:

[markmandel]

@lacroixthomas something to consider as you are working on the new allocation services.

[lacroixthomas]

It should indeed be working with the new allocation service (in work in progress - processorAllocator), I'll double check, but I can also see that indeed the context is not propagated currently, I can have a look at this / make a PR, will do some tests

[Reasonably]

@markmandel @lacroixthomas

I missed this point (https://github.com/googleforgames/agones/blob/main/pkg/gameserverallocations/allocator.go#L459-L473
). Simply passing the context does not fully solve the problem. Even if the context is cancelled, once a request has already been enqueued in pendingRequests, the processing continues to completion, which can result in orphaned allocated game servers.

A better approach would be to attach the context to the request itself and check whether it should be skipped based on that context during the queue processing stage(at ListenAndAllocate).

[lacroixthomas]

Ooh I see, I'll come back to my changes (will move that back to draft until ready), will have a deeper look around this, because indeed it should already handle it, but might be one step too "far" from what you described
Will poke you back when I have something

[lacroixthomas]

@Reasonably I've updated the PR, wasn't able to reproduce it properly locally, but if you've got the setup for it, you can use the builds from the PR: #4415 (comment)

I added the context on the request as you suggested, also checked before adding it to the pendingRequests but this might be overkill though

[github-actions]

'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '