Repository navigation
Promote CountsAndLists Feature Gate from Beta to Stable #4590
Description
What does this feature do?
CountsAndLists provides generic integer counter and string-list tracking on GameServers. It enables:
- Declaring named counters (integer) and lists (up to 1000 string values) on a GameServer at creation time
- Reading/updating those values via the SDK (
GetCounter,UpdateCounter,GetList,UpdateList,AddListValue,RemoveListValue) - Filtering GameServerAllocations based on counter/list capacity and priorities
- Fleet auto-scaling driven by available counter/list capacity
- Aggregated counter/list status rolled up to Fleet and GameServerSet
All SDK methods for this feature live in the beta SDK packages today (Go: sdks/go/beta.go, C#: sdks/csharp/sdk/Beta.cs, Rust: sdks/rust/src/beta.rs, Unity: sdks/unity/AgonesBetaSdk.cs).
Current state: Beta (enabled by default since v1.41.0)
⚠️ This is a large, cross-cutting change. It should be broken into multiple PRs to keep reviews manageable. A suggested breakdown is at the bottom of this issue.
Acceptance Criteria / Tasks
- Manual audit: Before starting, grep the repo for
FeatureCountsAndListsandCountsAndListsto confirm all usage sites (~378 occurrences today)
Feature gate removal
- API validation — Remove
FeatureCountsAndListsguards; fold to always-permitted:pkg/apis/agones/v1/gameserver.go— allow Counters/Lists fields unconditionallypkg/apis/agones/v1/fleet.go— allow Priorities unconditionallypkg/apis/agones/v1/gameserverset.go— allow Priorities unconditionallypkg/apis/autoscaling/v1/fleetautoscaler.go— allow CounterPolicy/ListPolicy unconditionallypkg/apis/allocation/v1/gameserverallocation.go— allow Counters/Lists/Priorities unconditionally
- Controllers — Always aggregate counter/list status:
pkg/gameserversets/controller.gopkg/fleets/controller.go
- Allocation — Remove gates from counter/list matching, sorting, and cache population:
pkg/gameserverallocations/allocator.go,allocation_cache.go,find.go,converter.go
- Fleet autoscaler —
pkg/fleetautoscalers/fleetautoscalers.go— remove CounterPolicy/ListPolicy gate - Sorting —
pkg/gameserversets/gameserversets.go— remove priority-sorting gate - Metrics —
pkg/metrics/controller.go— remove counter metric gate - SDK Server — Remove feature gate checks from all Counter/List RPC handlers in
pkg/sdkserver/sdkserver.goandpkg/sdkserver/localsdk.go
SDK promotion
Per the Agones SDK stability policy: when a Beta SDK feature graduates to Stable at release X, the Beta surface is marked deprecated at release X and removed 5 releases later.
- Copy Counter/List RPC definitions from
proto/sdk/beta/beta.protointoproto/sdk/sdk.proto— do not remove them frombeta.protoyet - Run
make gen-all-sdk-grpcto regenerate all SDK artifacts (stable stubs now exist alongside beta stubs) - For each language (Go, C#, Rust, Unity): add stable SDK implementations; mark the Beta SDK methods as deprecated in the beta files
- Update
[Stage:Beta]/[FeatureFlag:CountsAndLists]annotations in proto and SDK files to reflect stable status - Open a follow-up issue to remove the
beta.protodefinitions and beta implementations ~5 releases after this graduation
Config & docs
-
pkg/util/runtime/features.go— MoveFeatureCountsAndListsto// Stable features(keep infeatureDefaultsastrue) -
install/helm/agones/defaultfeaturegates.yaml— Move to Stable section -
build/Makefile— Remove fromBETA_FEATURE_GATES -
cloudbuild.yaml— RemoveCountsAndLists=falsefrom the inverted e2e config -
site/content/en/docs/Guides/feature-stages.md— Move row from Beta → Stable table -
site/content/en/docs/Guides/counters-and-lists.md— Remove Beta stage references -
site/content/en/docs/Installation/upgrading.md— Fill in the "Stable" column forGetCounter,UpdateCounter,GetList,UpdateList,AddListValue,RemoveListValuein the SDK API stability table with the graduation release version -
test/upgrade/versionMap.yaml— Add stable-gates entry for this release
Tests
- Remove
FeatureCountsAndListsskip guards from e2e tests:TestCounters,TestLists,TestCounterAndListGameServerAllocation,TestFleetAggregatedCounterStatus,TestFleetAggregatedListStatus, and all Counter/List autoscaler tests intest/e2e/ - Remove unit test feature-gate guards in
pkg/gameserversets/,pkg/fleetautoscalers/,pkg/gameserverallocations/
Suggested PR breakdown
Given the size of this work, splitting across multiple PRs is strongly recommended:
- PR 1 — API validation + tests: Remove gates from the five validation webhook files and their unit tests
- PR 2 — Controllers, allocation, autoscaler, metrics, sorting + tests: All the controller and allocation logic gate removal
- PR 3 — SDK server gate removal: Remove
FeatureCountsAndListschecks frompkg/sdkserver/sdkserver.goandpkg/sdkserver/localsdk.go - PR 4 — SDK proto + codegen: Copy Counter/List RPC definitions from
beta.protointosdk.proto(leavingbeta.protointact); runmake gen-all-sdk-grpcso stable stubs now exist alongside beta stubs — must land before per-language PRs - PR 5 (Go), PR 6 (C#), PR 7 (Rust), PR 8 (Unity) — Per-language SDK promotion: Add stable implementations; mark beta methods as deprecated in each language's beta file (do not delete yet — removal comes ~5 releases later via a follow-up issue)
- PR 9 — Config & docs:
features.go, Helm, Makefile, cloudbuild, feature-stages, counters-and-lists guide, upgrading.md SDK table, versionMap (can land any time after PRs 1–3 are merged)
Verification
make lint test-gopasses with noCountsAndLists-gated skips- E2E tests
TestCounters,TestLists, and all Counter/List allocation/autoscaler tests run without skip guards - A GameServer with counters/lists defined can be created without setting the feature gate
- Setting
CountsAndLists=trueorCountsAndLists=falsein the feature gate string must not cause a parse error (covered by keeping the const infeatureDefaults) make gen-all-sdk-grpcproduces no unexpected diff after the proto promotion
Activity
Devansh1093 commentedon Jun 2, 2026
I would like to work on the first pull request(API validation + tests).
Sivasankaran25 commentedon Jun 10, 2026
@Devansh1093 Thank you for your contribution. Could you please confirm if you are working on this issue? Or else, I can work on it
Devansh1093 commentedon Jun 10, 2026
You can work on it. I was not able to do it.
github-actions commentedon Jul 15, 2026
'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 '
igooch commentedon Sep 8, 2026
Adding that final promotion should wait until a fix is merged for #4680.
Beverly621 commentedon Oct 3, 2026
Hi @Sivasankaran25 and @markmandel,
I'd like to contribute to Agones and I'm interested specifically in PR 3 — SDK server gate removal from this issue.
I see that #4733 (PR 1) has already landed and #4760 (PR 2) is currently in progress, and that the umbrella issue is assigned to @Sivasankaran25, so I don't want to duplicate or compete with ongoing work.
If PR 3 is not already planned/in progress, would it be okay for me to take just that slice?
:)
Sivasankaran25 commentedon Oct 4, 2026
Hi @Beverly621 , thank you for your contribution to this repo!
PR 3 is already completed and is waiting for PR 2 to be approved and merged. Once PR 2 is merged, PR 3 will be raised.
So, if that’s okay with you, please pick any of the remaining PRs for this issue.
Beverly621 commentedon Oct 4, 2026
👀Thanks for clarifying, @Sivasankaran25. I've opened PR 4 — SDK proto + codegen: #4765
The PR adds the six Counter/List RPCs to the stable protocol and regenerates SDK artifacts, preserving beta compatibility.
SDK server gate removal and per-language SDK promotion remain in their separate PRs.
The agreed checks passed, including native AMD64 C# Release publish on Google Cloud; validation details are in the PR.
markmandel commentedon Oct 10, 2026
Looking at #4765 for an example of PR4 -- I think we should be able to split this out into much smaller chunks.
And as I look closer at your plan -- that's actually more aligned with what you said in your original PR issue - PR4 should just be the proto change and the code gen -- each sdk could then be handled individually, which is much easier to review.
So good planning up front 👍🏻 for sure, let's definitely stick to that.