Skip to content

Promote CountsAndLists Feature Gate from Beta to Stable #4590

Open

Description

@markmandel

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 FeatureCountsAndLists and CountsAndLists to confirm all usage sites (~378 occurrences today)

Feature gate removal

  • API validation — Remove FeatureCountsAndLists guards; fold to always-permitted:
    • pkg/apis/agones/v1/gameserver.go — allow Counters/Lists fields unconditionally
    • pkg/apis/agones/v1/fleet.go — allow Priorities unconditionally
    • pkg/apis/agones/v1/gameserverset.go — allow Priorities unconditionally
    • pkg/apis/autoscaling/v1/fleetautoscaler.go — allow CounterPolicy/ListPolicy unconditionally
    • pkg/apis/allocation/v1/gameserverallocation.go — allow Counters/Lists/Priorities unconditionally
  • Controllers — Always aggregate counter/list status:
    • pkg/gameserversets/controller.go
    • pkg/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.go and pkg/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.proto into proto/sdk/sdk.proto — do not remove them from beta.proto yet
  • Run make gen-all-sdk-grpc to 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.proto definitions and beta implementations ~5 releases after this graduation

Config & docs

  • pkg/util/runtime/features.go — Move FeatureCountsAndLists to // Stable features (keep in featureDefaults as true)
  • install/helm/agones/defaultfeaturegates.yaml — Move to Stable section
  • build/Makefile — Remove from BETA_FEATURE_GATES
  • cloudbuild.yaml — Remove CountsAndLists=false from 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 for GetCounter, UpdateCounter, GetList, UpdateList, AddListValue, RemoveListValue in the SDK API stability table with the graduation release version
  • test/upgrade/versionMap.yaml — Add stable-gates entry for this release

Tests

  • Remove FeatureCountsAndLists skip guards from e2e tests: TestCounters, TestLists, TestCounterAndListGameServerAllocation, TestFleetAggregatedCounterStatus, TestFleetAggregatedListStatus, and all Counter/List autoscaler tests in test/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:

  1. PR 1 — API validation + tests: Remove gates from the five validation webhook files and their unit tests
  2. PR 2 — Controllers, allocation, autoscaler, metrics, sorting + tests: All the controller and allocation logic gate removal
  3. PR 3 — SDK server gate removal: Remove FeatureCountsAndLists checks from pkg/sdkserver/sdkserver.go and pkg/sdkserver/localsdk.go
  4. PR 4 — SDK proto + codegen: Copy Counter/List RPC definitions from beta.proto into sdk.proto (leaving beta.proto intact); run make gen-all-sdk-grpc so stable stubs now exist alongside beta stubs — must land before per-language PRs
  5. 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)
  6. 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-go passes with no CountsAndLists-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=true or CountsAndLists=false in the feature gate string must not cause a parse error (covered by keeping the const in featureDefaults)
  • make gen-all-sdk-grpc produces no unexpected diff after the proto promotion

Activity

  1. added
    kind/cleanupRefactoring code, fixing up documentation, etc
    help wantedWe would love help on these issues. Please come help us!
    on May 31, 2026
  2. Devansh1093 commented on Jun 2, 2026

    @Devansh1093

    I would like to work on the first pull request(API validation + tests).

  3. Sivasankaran25 commented on Jun 10, 2026

    @Sivasankaran25
    Collaborator

    @Devansh1093 Thank you for your contribution. Could you please confirm if you are working on this issue? Or else, I can work on it

  4. Devansh1093 commented on Jun 10, 2026

    @Devansh1093

    You can work on it. I was not able to do it.

  5. github-actions commented on Jul 15, 2026

    @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 '

  6. added
    stalePending closure unless there is a strong objection.
    on Jul 15, 2026
  7. added
    awaiting-maintainerBlock issues from being stale/obsolete/closed
    and removed
    stalePending closure unless there is a strong objection.
    on Jul 15, 2026
  8. igooch commented on Sep 8, 2026

    @igooch
    Collaborator

    Adding that final promotion should wait until a fix is merged for #4680.

  9. Beverly621 commented on Oct 3, 2026

    @Beverly621

    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?

    :)

  10. Sivasankaran25 commented on Oct 4, 2026

    @Sivasankaran25
    Collaborator

    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?

    :)

    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.

  11. Beverly621 commented on Oct 4, 2026

    @Beverly621

    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?
    :)

    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.

    👀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.

  12. markmandel commented on Oct 10, 2026

    @markmandel
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

awaiting-maintainerBlock issues from being stale/obsolete/closedhelp wantedWe would love help on these issues. Please come help us!kind/cleanupRefactoring code, fixing up documentation, etc

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions