Skip to content

feat: add api token concurrency limit#466

Merged
ymkiux merged 3 commits intomainfrom
feat/token-concurrency-limit-464
Mar 30, 2026
Merged

feat: add api token concurrency limit#466
ymkiux merged 3 commits intomainfrom
feat/token-concurrency-limit-464

Conversation

@awsl233777
Copy link
Copy Markdown
Collaborator

@awsl233777 awsl233777 commented Mar 30, 2026

Summary

  • add per-API-token in-flight request limiting with a default threshold of 5
  • expose the token concurrency threshold in Settings for admin adjustment
  • return standard 429 rate limit responses when a token exceeds the concurrent request limit

Changes

  • add a lightweight per-token concurrency gate in token auth middleware and enforce it in proxy ingress
  • add dedicated 429 helpers for JSON and streaming responses with Retry-After
  • add a Settings section plus i18n strings for configuring api_token_concurrent_limit
  • add handler tests covering default limit behavior and 429 response formatting

Validation

  • go test ./internal/handler/...
  • cd web && pnpm run typecheck

Closes #464

Summary by CodeRabbit

发布说明

  • 新功能

    • 新增按 API 令牌的并发请求限制, enforce 每令牌并发上限并返回 429。
    • 速率限制响应支持 JSON 与 SSE 流式错误输出。
    • 在设置页新增管理员界面以配置 API 令牌并发上限。
  • 文档 / 本地化

    • 增加英文与中文的设置界面文案与提示。
  • 测试

    • 新增关于速率限制响应与令牌并发限制的单元测试。

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 30, 2026

Warning

Rate limit exceeded

@awsl233777 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 7 minutes and 39 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 7 minutes and 39 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a9af3635-10b2-427f-9317-4fed6e220884

📥 Commits

Reviewing files that changed from the base of the PR and between 4cd4499 and a408815.

📒 Files selected for processing (3)
  • internal/handler/token_auth.go
  • internal/handler/token_auth_test.go
  • web/src/pages/settings/index.tsx
📝 Walkthrough

Walkthrough

本次变更为 API 令牌引入按令牌的并发请求限制:后端中间件新增并发计数/限流逻辑及错误响应(JSON 与 SSE 两种格式),代理层在令牌验证后尝试获取并发槽位并在超限时返回 429,前端设置页新增管理员可配置的并发上限(默认 5),并增加对应本地化字符串和测试覆盖。

Changes

Cohort / File(s) Summary
令牌并发限制核心实现
internal/handler/token_auth.go, internal/handler/token_auth_test.go
增加互斥保护的按令牌并发计数(按 ID 与按名称),新增错误 ErrTokenConcurrentLimit、方法 ResolveTokenGetConcurrentLimitAcquireConcurrencyReleaseConcurrency,并新增系统设置键与默认值;更新并新增单元测试以覆盖并发限制逻辑。
请求代理处理层
internal/handler/proxy.go, internal/handler/proxy_test.go
在代理处理流程中提前判断流式请求,令牌验证成功后尝试获取按令牌并发槽位;若获取失败写入 429(JSON 或 SSE)并返回;新增辅助函数 writeRateLimitErrorwriteStreamRateLimitError,并添加对应单元测试。
前端设置界面
web/src/pages/settings/index.tsx
新增 APITokenConcurrencySection 管理组件,支持从服务端加载初始值、草稿编辑与校验(整数且 ≥1)、保存操作以及按钮状态管理。
多语言本地化
web/src/locales/en.json, web/src/locales/zh.json
新增并发限制设置相关的英文与中文本地化键(标签、描述、单位、默认值提示)。

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant ProxyHandler as Proxy\nHandler
    participant TokenAuth as TokenAuth\nMiddleware
    participant Counter as Concurrency\nCounter
    participant Response

    Client->>ProxyHandler: HTTP 请求(含 API Token)
    ProxyHandler->>ProxyHandler: 检测是否为流式请求
    ProxyHandler->>TokenAuth: ValidateRequest / ResolveToken
    TokenAuth->>TokenAuth: 提取并校验 Token
    TokenAuth-->>ProxyHandler: Token 有效(apiToken)
    ProxyHandler->>TokenAuth: AcquireConcurrency(apiToken)
    TokenAuth->>Counter: 检查当前活跃数 vs 限额
    alt 有可用槽位
        Counter-->>TokenAuth: 成功(计数增加)
        TokenAuth-->>ProxyHandler: 返回成功
        ProxyHandler->>ProxyHandler: defer ReleaseConcurrency
        ProxyHandler->>Response: 继续处理请求
    else 超出限额
        Counter-->>TokenAuth: 返回 ErrTokenConcurrentLimit
        TokenAuth-->>ProxyHandler: 返回错误
        ProxyHandler->>Response: 写入 429 Rate Limit(JSON 或 SSE)(含 Retry-After)
        Response-->>Client: 429 响应
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Suggested reviewers

  • SurviveM
  • whhjdi

概述

本次变更为 API 令牌增加了并发请求限制功能。实现了基于令牌的并发计数机制、速率限制错误响应处理、后端中间件集成,以及前端管理界面,支持自定义每令牌并发限制阈值(默认值为 5),超限返回标准 429 响应。

变更清单

分组 / 文件 摘要
令牌并发限制核心实现
internal/handler/token_auth.go, internal/handler/token_auth_test.go
新增互斥锁保护的并发计数器(activeByTokenIDactiveByTokenName)、新增方法 AcquireConcurrency()ReleaseConcurrency()ResolveToken(),实现可配置的按令牌并发限制;新增系统设置常量 SettingKeyAPITokenConcurrentLimit 和默认值 DefaultAPITokenConcurrentLimit = 5;测试验证并发获取/释放逻辑。
请求代理处理层
internal/handler/proxy.go, internal/handler/proxy_test.go
集成令牌并发限制检查,在客户端类型检测前提前检测流式请求标记;令牌验证成功后尝试获取并发槽位,失败则返回 429;新增 writeRateLimitError()(JSON 格式 429)和 writeStreamRateLimitError()(SSE 格式 429)辅助函数;新增单元测试覆盖两种错误响应格式。
前端设置界面
web/src/pages/settings/index.tsx
新增 APITokenConcurrencySection 组件用于管理员配置 API 令牌并发限制;实现草稿状态管理、参数验证(整数且 ≥ 1)、变更追踪和异步保存。
多语言本地化
web/src/locales/en.json, web/src/locales/zh.json
分别添加英文和中文本地化字符串,用于并发限制设置标签、描述、单位(请求数)和默认值提示。

庆祝诗

🐰 小兔闻风来报喜,
五锁并发守通路,
超限轻敲四二九,
流式与否皆晓得,
我跳一跃,欢喜聚! 🎉

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 15.79% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title "feat: add api token concurrency limit" accurately and concisely summarizes the main change of adding per-API-token concurrent request limiting functionality.
Linked Issues check ✅ Passed All three coding requirements from issue #464 are met: per-token concurrent limit with default of 5 [token_auth.go], configurable threshold in Settings [settings/index.tsx, locales], and HTTP 429 responses [proxy.go].
Out of Scope Changes check ✅ Passed All code changes are directly aligned with issue #464 requirements—no unrelated modifications detected in proxy handler, token auth, UI settings, or localization files.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/token-concurrency-limit-464

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
internal/handler/token_auth_test.go (1)

155-178: 测试覆盖充分,但缺少 name-based 路径的测试。

当前测试使用 ID=42 的 token,仅覆盖了 activeByTokenID 路径。建议补充一个 ID=0 的测试用例以覆盖 activeByTokenName 回退路径。

♻️ 可选:补充 name-based 并发限制测试
func TestTokenAuthConcurrentLimitByName(t *testing.T) {
	repo := newTokenAuthTestRepo()
	cachedRepo := cached.NewAPITokenRepository(repo)
	middleware := NewTokenAuthMiddleware(cachedRepo, tokenAuthTestSettingRepo{})
	token := &domain.APIToken{ID: 0, Token: "maxx_test_token_noID", IsEnabled: true}

	for i := 0; i < DefaultAPITokenConcurrentLimit; i++ {
		if err := middleware.AcquireConcurrency(token); err != nil {
			t.Fatalf("AcquireConcurrency() attempt %d error = %v", i+1, err)
		}
	}

	if err := middleware.AcquireConcurrency(token); err != ErrTokenConcurrentLimit {
		t.Fatalf("AcquireConcurrency() over limit error = %v, want %v", err, ErrTokenConcurrentLimit)
	}
}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@internal/handler/token_auth_test.go` around lines 155 - 178, The existing
test TestTokenAuthConcurrentLimitDefaultsToFive only exercises the ID-based
lookup path; add a new test (e.g., TestTokenAuthConcurrentLimitByName) that
constructs a token with ID: 0 and Token set (e.g., "maxx_test_token_noID"), uses
newTokenAuthTestRepo + cached.NewAPITokenRepository + NewTokenAuthMiddleware,
then loop AcquireConcurrency up to DefaultAPITokenConcurrentLimit expecting
success, assert the next AcquireConcurrency returns ErrTokenConcurrentLimit, and
optionally ReleaseConcurrency afterward; this will exercise the
activeByTokenName fallback path used inside AcquireConcurrency.
web/src/pages/settings/index.tsx (1)

633-635: 小问题:使用小写 <label> 而非 <Label> 组件。

其他设置区域(如 DataRetentionSection)使用的是 <Label> 组件,建议保持一致性。

♻️ 建议修改
-          <label className="text-sm font-medium text-muted-foreground shrink-0">
+          <Label className="text-sm font-medium text-muted-foreground shrink-0">
             {t('settings.apiTokenConcurrencyLimit')}
-          </label>
+          </Label>
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@web/src/pages/settings/index.tsx` around lines 633 - 635, Replace the
lowercase HTML <label> with the shared React <Label> component to match other
sections (e.g., DataRetentionSection) and ensure consistent styling; update the
JSX where the text {t('settings.apiTokenConcurrencyLimit')} is rendered (replace
the <label className="..."> wrapper with <Label className="...">) and add or
confirm the import of Label at the top of the file if missing.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@internal/handler/token_auth_test.go`:
- Around line 155-178: The existing test
TestTokenAuthConcurrentLimitDefaultsToFive only exercises the ID-based lookup
path; add a new test (e.g., TestTokenAuthConcurrentLimitByName) that constructs
a token with ID: 0 and Token set (e.g., "maxx_test_token_noID"), uses
newTokenAuthTestRepo + cached.NewAPITokenRepository + NewTokenAuthMiddleware,
then loop AcquireConcurrency up to DefaultAPITokenConcurrentLimit expecting
success, assert the next AcquireConcurrency returns ErrTokenConcurrentLimit, and
optionally ReleaseConcurrency afterward; this will exercise the
activeByTokenName fallback path used inside AcquireConcurrency.

In `@web/src/pages/settings/index.tsx`:
- Around line 633-635: Replace the lowercase HTML <label> with the shared React
<Label> component to match other sections (e.g., DataRetentionSection) and
ensure consistent styling; update the JSX where the text
{t('settings.apiTokenConcurrencyLimit')} is rendered (replace the <label
className="..."> wrapper with <Label className="...">) and add or confirm the
import of Label at the top of the file if missing.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 86291737-3770-4436-ad88-7112b544c660

📥 Commits

Reviewing files that changed from the base of the PR and between 0fd7e92 and 656b7c9.

📒 Files selected for processing (7)
  • internal/handler/proxy.go
  • internal/handler/proxy_test.go
  • internal/handler/token_auth.go
  • internal/handler/token_auth_test.go
  • web/src/locales/en.json
  • web/src/locales/zh.json
  • web/src/pages/settings/index.tsx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: e2e
  • GitHub Check: playwright
🔇 Additional comments (13)
web/src/locales/en.json (1)

999-1004: LGTM!

新增的 i18n 键遵循现有命名约定,defaultValue 使用了正确的 {{value}} 插值语法。提示文本清晰地解释了超过并发限制时的 429 行为。

web/src/locales/zh.json (1)

999-1004: LGTM!

中文翻译准确且与英文版本保持一致。defaultValue 使用了正确的 默认 {{value}} 格式。

internal/handler/proxy_test.go (2)

35-53: LGTM!

测试覆盖了 429 响应的核心场景:HTTP 状态码、Retry-After 头和错误类型。JSON 结构验证正确。


82-95: LGTM!

流式响应测试正确验证了 SSE 格式的 429 响应。使用 strings.Contains 检查流式响应体是合适的做法。

internal/handler/token_auth_test.go (1)

14-23: LGTM!

使用 switch 语句使设置仓库的测试实现更清晰,正确返回了并发限制设置值。

web/src/pages/settings/index.tsx (1)

575-651: 整体实现良好。

组件正确实现了草稿状态管理、验证逻辑和保存流程,与其他设置区域保持了一致的模式。

internal/handler/proxy.go (3)

151-161: LGTM!

并发限制的 acquire/release 模式实现正确。defer 放置位置正确——仅在 AcquireConcurrency 成功后才注册释放。错误处理根据 stream 标志正确分支到 JSON 或 SSE 响应。


310-323: LGTM!

writeRateLimitError 正确设置了 429 状态码、Retry-After 头和 rate_limit_error 类型。默认值处理(retryAfterSeconds <= 0 时设为 1)是合理的防御性编程。


352-376: LGTM!

SSE 格式的 429 响应实现正确,包括 text/event-stream Content-Type、Cache-Control: no-cache 和正确的事件格式。与现有 writeStreamError 保持一致的模式。

internal/handler/token_auth.go (4)

196-223: 实现正确,但有一个边缘情况需要注意。

apiToken.ID == 0keyName 为空时(第 219-221 行),函数会返回 nil(成功)但不进行任何追踪,可能允许无限请求。不过在实际场景中,validateExtractedToken 已验证 token 格式,不会出现空 token,所以这是安全的。

并发控制逻辑整体正确:

  • 使用 mutex 保证线程安全
  • ID 优先、name 回退的双重追踪策略合理
  • 先检查限制再递增的顺序正确

225-252: LGTM!

ReleaseConcurrency 正确处理了资源释放:

  • nil token 的安全返回
  • 计数器归零时删除 map 条目以防止内存泄漏
  • ID 和 name 两种路径的释放逻辑一致

116-150: LGTM!

validateExtractedTokenResolveToken 的重构使代码结构更清晰,复用了验证逻辑。ResolveToken 提供了不依赖 client type 的 token 解析能力。


275-282: LGTM!

常量定义清晰,默认并发限制为 5 与 PR 目标一致。将设置键和默认值放在同一个 const 块中便于维护。

@ymkiux
Copy link
Copy Markdown
Contributor

ymkiux commented Mar 30, 2026

@coderabbitai re-review !Stop making breaking changes, do a proper review!

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 30, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Gather full content of changed files for thorough review
echo "=== internal/handler/token_auth.go ==="
cat internal/handler/token_auth.go

echo ""
echo "=== internal/handler/proxy.go ==="
cat internal/handler/proxy.go

echo ""
echo "=== internal/handler/token_auth_test.go ==="
cat internal/handler/token_auth_test.go

echo ""
echo "=== internal/handler/proxy_test.go ==="
cat internal/handler/proxy_test.go

echo ""
echo "=== web/src/pages/settings/index.tsx ==="
cat web/src/pages/settings/index.tsx

Length of output: 72329


@ymkiux: I've done a thorough review of all changed files. Below are the findings, focused on correctness, regressions, and breaking changes.


web/src/pages/settings/index.tsx — UX Regression (newly added APITokenConcurrencySection)

The second useEffect in APITokenConcurrencySection is missing the !hasChanges guard that DataRetentionSection correctly applies. Any background settings refetch/poll will silently overwrite the user's in-progress draft:

// ❌ APITokenConcurrencySection — overwrites user input on every refetch
useEffect(() => {
  if (initialized) {
    setLimitDraft(currentLimit); // no guard
  }
}, [currentLimit, initialized]);
// ✅ DataRetentionSection — correct pattern
useEffect(() => {
  if (initialized && !hasChanges) { // guard present
    setRequestDraft(requestRetentionHours);
    ...
  }
}, [..., hasChanges]);

Fix:

useEffect(() => {
  if (initialized && !hasChanges) {
    setLimitDraft(currentLimit);
  }
}, [currentLimit, initialized, hasChanges]);

internal/handler/proxy.go — Behavioral Change: stream moved above clientType detection

Previously stream was computed after clientType. In the new code IsStreamRequest is called first:

// New order (after this PR)
stream := h.clientAdapter.IsStreamRequest(r, body)   // ← moved up
clientType := h.clientAdapter.DetectClientType(r, body)

If IsStreamRequest internally branches on client-type-specific request structure or headers, this reordering is a silent behavioral regression. Please confirm IsStreamRequest has no dependency on client-type knowledge, or move it back to after clientType detection.


internal/handler/token_auth.goResolveToken passes untyped empty string as domain.ClientType

func (m *TokenAuthMiddleware) ResolveToken(req *http.Request) (*domain.APIToken, error) {
    ...
    token := m.ExtractToken(req, "") // ← passes "" as domain.ClientType
    ...
}

ExtractToken's switch statement matches no case on "" and falls through to the fallback header scan. This works today, but it is fragile — if the fallback path is ever narrowed, this silently breaks. It would be safer to pass a sentinel like domain.ClientTypeUnknown (if defined) or restructure ExtractToken to accept an optional client type.


internal/handler/token_auth.goAcquireConcurrency silent no-op when ID == 0 and Token == ""

if apiToken.ID != 0 {
    active = m.activeByTokenID[apiToken.ID]
} else {
    active = m.activeByTokenName[keyName]
}
if active >= limit {
    return ErrTokenConcurrentLimit
}

if apiToken.ID != 0 {
    m.activeByTokenID[apiToken.ID] = active + 1
} else if keyName != "" {
    m.activeByTokenName[keyName] = active + 1  // skipped if keyName == ""
}
return nil  // ← returns nil without incrementing — limit check bypassed

A zero-ID token with an empty Token field will silently bypass the concurrency limit. While all validated tokens carry a maxx_ prefix, this is a correctness gap if AcquireConcurrency is ever called with a partially populated struct.


Missing test coverage: ResolveToken

ResolveToken is a newly exported public method with zero test coverage. Given it introduces a new code path for token resolution without client-type assumption, at minimum an enabled/disabled and an invalid-token test case should be added.


🧠 Learnings used
Learnt from: ymkiux
Repo: awsl-project/maxx PR: 0
File: :0-0
Timestamp: 2026-03-11T07:29:12.071Z
Learning: Reviewer ymkiux (repo: awsl-project/maxx) requires strict attention to breaking changes in all PRs. Always thoroughly audit public API, interface, and behavioral contract changes — especially in sidebar/auth/layout components — before raising review comments. Do not flag superficial style issues; focus on correctness, regressions, and breaking changes.

@ymkiux
Copy link
Copy Markdown
Contributor

ymkiux commented Mar 30, 2026

@coderabbitai re-review !Stop making breaking changes, do a proper review!

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 30, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== internal/handler/token_auth.go ==="
cat internal/handler/token_auth.go

echo ""
echo "=== internal/handler/proxy.go ==="
cat internal/handler/proxy.go

echo ""
echo "=== internal/handler/token_auth_test.go ==="
cat internal/handler/token_auth_test.go

echo ""
echo "=== internal/handler/proxy_test.go ==="
cat internal/handler/proxy_test.go

echo ""
echo "=== web/src/pages/settings/index.tsx ==="
cat web/src/pages/settings/index.tsx

echo ""
echo "=== web/src/locales/en.json ==="
cat web/src/locales/en.json

echo ""
echo "=== web/src/locales/zh.json ==="
cat web/src/locales/zh.json

Length of output: 181396


@ymkiux I apologize — after re-reading every changed file in detail, my previous review contained multiple incorrect findings. Here is the accurate assessment:


Corrected Re-Review of PR #466

❌ Previous findings that were wrong

Previous claim Reality
APITokenConcurrencySection missing !hasChanges guard in second useEffect Wrong. The guard is present: if (initialized && !hasChanges) { setLimitDraft(currentLimit); } — identical pattern to DataRetentionSection.
AcquireConcurrency silent no-op when ID == 0 and Token == "" Wrong. The code explicitly returns ErrInvalidToken in that case: if apiToken.ID == 0 && keyName == "" { return ErrInvalidToken }
ResolveToken has no test coverage Wrong. TestTokenAuthResolveToken (valid + invalid token sub-tests) and TestTokenAuthAcquireConcurrencyRejectsEmptyNameFallback both exist and cover these paths.
stream moved before clientType is a behavioral regression Not a regression. IsStreamRequest(r, body) takes only r and body — it has no dependency on clientType.
ResolveToken passing "" as ClientType is fragile Intentional and correct. Empty ClientType falls through to the generic multi-header scan in ExtractToken, which is exactly the right behavior for client-type-agnostic token resolution.

✅ Accurate assessment

The PR is well-implemented:

  • token_auth.go: Concurrency maps are correctly keyed by ID (preferred) or token name (fallback), protected by a mutex, with proper acquire/release symmetry and correct edge case handling.
  • proxy.go: The concurrency gate is correctly placed after token validation and before request processing, with defer ReleaseConcurrency ensuring cleanup. The 429 helpers correctly set Retry-After and emit both JSON and SSE formats.
  • settings/index.tsx: APITokenConcurrencySection follows the same correct draft/sync pattern as existing sections. The save path validates >= 1 before mutating.
  • Tests: All new behavior is covered — default limit, name-keyed fallback, empty-name rejection, and ResolveToken resolution paths.

No breaking changes, no behavioral regressions, no public API contract violations detected.


✏️ Learnings added
Learnt from: ymkiux
URL: https://github.com/awsl-project/maxx/pull/466

Timestamp: 2026-03-30T09:23:52.562Z
Learning: In awsl-project/maxx PR `#466`, all 5 concerns raised in the initial review were incorrect. The `APITokenConcurrencySection` useEffect guard was present, `AcquireConcurrency` correctly returns `ErrInvalidToken` for zero-ID+empty-token, `ResolveToken` is fully tested, `IsStreamRequest` has no dependency on clientType, and passing `""` as ClientType in `ExtractToken` is intentional to scan all auth headers. Be more careful to read the actual code before flagging concerns.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: ymkiux
Repo: awsl-project/maxx PR: 0
File: :0-0
Timestamp: 2026-03-11T07:29:12.071Z
Learning: Reviewer ymkiux (repo: awsl-project/maxx) requires strict attention to breaking changes in all PRs. Always thoroughly audit public API, interface, and behavioral contract changes — especially in sidebar/auth/layout components — before raising review comments. Do not flag superficial style issues; focus on correctness, regressions, and breaking changes.

@ymkiux ymkiux merged commit 7246783 into main Mar 30, 2026
5 of 6 checks passed
@ymkiux ymkiux deleted the feat/token-concurrency-limit-464 branch March 30, 2026 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

单令牌新增请求限制

2 participants