Remove legacy user generation label handling

[strideynet]

Closes #64484

A long long time ago, we stored a generation counter on the Bot User as a label. Less long ago, we began to migrate to storing this generation counter on Bot Instances.

As part of this migration, we continued to write the legacy generation counter label (to support downgrade paths gracefully) and included logic which would create a Bot Instance, if one did not exist, from the bot user label. This migration began in #44583 - and began without an experiment flag in v17.0.0.

From this PR onwards:

• We no longer write the generation counter label.
• We no longer restore Bot Instances from the generation counter label.
• If the BotInstance cannot be found, this is treated as a generation mismatch for Token and Bound Keypair joining and triggers a lock of the join token.

I also took this opportunity to clean up the updateBotInstance method - this had become very difficult to understand and had a number of branches. As the migration to Bot Instances took place long enough ago, we can now safely assume things like the Generation and BotInstanceID will be encoded in identities.

Open question:

Is treating BotInstance not found as a generation mismatch (and hence a lock for Token/Bound Keypair joining) reasonable? Locking the join token is quite a drastic action and prevents self-recovery (for bound keypair). I went with this approach in the PR, since it most closely tracks the existing behaviour today.

As far as I can tell, there are two cases where we may expect the BotInstance to not be found:

• Administrative rollback of the database (or disaster recovery)
• Administrator invokes DeleteBotInstance RPC.

It seems increasingly reasonable to me that we may wish to treat this as an error and reject the renewal without locking. This would allow self-recovery for Bound Keypair. However, I do believe this would be better explored in a separate PR as this would constitute a change in behaviour and security model. We would need to ensure that the Bound Keypair logic can handle the underlying layers changing the BotInstanceID. It doesn't necessarily resolve the problem either - since generation mismatch would be triggered if the BotInstance was rolled back to a prior counter value (and not non-existent).

Changelog:

Manual Test Plan

Test Environment

Local cluster

Test Cases

• Renew Bot Instance from prior version:
  • Token
  • Bound Keypair
  • Kubernetes
• Join Bot Instance:
  • Token
  • Bound Keypair
  • Kubernetes

Agentic test plan: https://gist.github.com/strideynet/f2c237c0652cce84bab1b2d2a8303b9d

[github-actions]

Amplify deployment status

Branch	Commit	Job ID	Status	Preview	Updated (UTC)
strideynet/remove-legacy-generation-label	bb4bd8d	9	✅SUCCEED	strideynet-remove-legacy-generation-label	2026-08-10 12:01:53

---

Preview links for changed docs pages

• docs/pages/machine-workload-identity/troubleshooting.mdx

[timothyb89]

Nice to see the legacy counter gone!