From ccb58d223af340bce966a6db836b546fb882a9ec Mon Sep 17 00:00:00 2001 From: fylorn <249551762+fylorn@users.noreply.github.com> Date: Tue, 20 Oct 2026 21:32:08 +0800 Subject: [PATCH] Fix the rotation comment: key limits follow the lineage Rate-limit rules and budgets are attached to the key's lineage_id, which the rotated key keeps, so they carry over without a copy step. Co-Authored-By: Claude Opus 5.5 --- crates/server/src/handlers/api_keys.rs | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/crates/server/src/handlers/api_keys.rs b/crates/server/src/handlers/api_keys.rs index bfe70a7f..68cf3798 100644 --- a/crates/server/src/handlers/api_keys.rs +++ b/crates/server/src/handlers/api_keys.rs @@ -927,11 +927,10 @@ pub async fn rotate_key( .await; let grace_period_ends_at = chrono::Utc::now() + chrono::Duration::hours(grace_hours); - // Generate new key. Rate-limit / budget rules attached to the - // OLD key id are NOT copied here — they live in `rate_limit_rules` - // / `budget_caps` keyed by api_key UUID. The follow-up phase - // ("limits attached to api_keys") will add an explicit copy step - // when rotation happens. + // Generate new key. Nothing to copy for limits: the key's + // rate-limit rules and budgets are attached to its `lineage_id` + // (`api_key_lineage` subjects, see `think_watch_common::limits`), + // and the new key keeps that lineage, so they carry over as is. let generated = api_key::generate_api_key(); // The new key carries the old one's name verbatim — the chain is