fix: the Redis problem in the CacheGetUsername function - #45
Merged
Conversation
fix: the Redis problem in the CacheGetUsername function
sususu98
pushed a commit
to sususu98/new-api
that referenced
this pull request
Dec 1, 2025
- 将优先级说明从 "(0最高)" 改为 "(数值越小优先级越高，0为最高)" - 消除用户对优先级排序规则的理解歧义 - 明确说明数值越小优先级越高，0为最高优先级 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
x22x22
pushed a commit
to x22x22/new-api
that referenced
this pull request
Apr 24, 2026
x22x22
pushed a commit
to x22x22/new-api
that referenced
this pull request
Apr 24, 2026
fix: the Redis problem in the CacheGetUsername function
jiutubaba
pushed a commit
to jiutubaba/fx-api
that referenced
this pull request
May 17, 2026
* fix(middleware): 修复 Gemini API Key 认证中间件用户上下文类型错误 修复了 ApiKeyAuthWithSubscriptionGoogle 中间件中设置用户上下文时的类型错误。 **问题:** - 中间件直接设置 `apiKey.User` 对象到上下文 - 导致 handler 中获取 `AuthSubject` 时类型断言失败 - 所有 Gemini v1beta 端点返回 500 "User context not found" **修复:** - 改为设置 `AuthSubject` 结构体,与 `api_key_auth.go` 保持一致 - 添加 `ContextKeyUserRole` 设置以完整支持角色检查 **影响范围:** - Gemini v1beta API 端点 (generateContent, streamGenerateContent) - 使用 Google API Key 认证的所有请求 **测试:** - 验证 Gemini CLI 调用成功返回 200 - 确认用户上下文正确传递到 handler * fix(web): 修复 /responses 端点被前端中间件拦截的问题 - 将 /responses 路径添加到 API 白名单，防止其被当作前端路由处理 - 修复 /responses 端点返回 HTML 而非 API 响应的 BUG - 解决 codex CLI stream 在远程服务器上断开连接的问题 根本原因: 在 6c469b4 提交中添加了 /responses 路由，但未同步更新前端嵌入中间件 的 API 白名单，导致该路由被拦截并返回 index.html 而非 API 响应。
lingozhi
pushed a commit
to lingozhi/new-api
that referenced
this pull request
Jul 17, 2026
Measured over 262 prod requests, all six channels serving the SAME model at the SAME reasoning effort — so the spread is the channel, not the request: #41 1275ms (n=90) QuantumNous#51 1328ms (n=66) QuantumNous#42 2337ms (n=17) #33 3388ms (n=24) QuantumNous#45 3537ms (n=52) QuantumNous#57 8133ms (n=8) Bucketing by uncached prompt tokens holds p50 flat (1612/1934/2073/1802 for 0-2k/2-6k/6-20k/20k+), which rules out prefill volume as the cause. Meanwhile ~100% of requests are affinity-pinned, so the health-weighted selection that was supposed to steer around slow channels almost never runs — the only exit is IsChannelFastEnoughForAffinity, and `score > 0.1` with `score = 1/(1+latency)` only fires past 9s. QuantumNous#45 and QuantumNous#57 kept their sticky traffic forever; 33% of requests were pinned to a channel 2.6x+ slower than the one next to it. Release relative to the best peer for the same model+path instead: leave only when the sticky is BOTH slower than 2s absolute and >2x that peer. The absolute floor stops churn over gaps nobody can feel (0.3s vs 0.15s is 2x), the ratio stops churn for gains too small to repay a migration. QuantumNous#42 at 1.83x stays. The reason this could not just be turned on: migration causes a cold prompt cache by construction, and a cold 240k-token prefill measured 23348ms. That one number breaks two mechanisms at once, both of which then punish the channel we just chose *for being the fastest*: - the latency EWMA, which is shared by every affinity key on the channel, so one migration would make the destination look slow to all of them and stampede them off it, each paying its own cold prefill; - cooldownSlowChannelIfNeeded, an entirely separate path that yanks a channel out of rotation for 30 minutes past 30s FRT — 23.3s is 78% of that. So the release is gated three ways. ColdCacheStart marks the attempt and keeps its latency out of both mechanisms (failures still count — a cold start is no excuse for erroring). A per-key cooldown stops one key bouncing. A global minimum interval drains a slow channel one key at a time, because the slow verdict is per-channel: without it every key pinned to QuantumNous#45 leaves on the same tick and their cold prefills land on #41 together, making it genuinely slow — a cascade no latency-exclusion can prevent, since that load is real. Circuit-open releases stay unconditional and never reach AcquireChannelHealth, or a rate-limited key would be parked on a tripped channel and a paying request would become its half-open probe. Accepted: weighted re-selection can hand a released key back to the same slow channel (~12.5% by weight). Not excluded — that risks a 503, and the cache there is still warm, so the only cost is the 10-minute slot. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Firesuiry
pushed a commit
to Firesuiry/tako-newapi
that referenced
this pull request
Aug 27, 2026
…ls-embed feat(playground): search, speech, and copyable skill cards
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix: the Redis problem in the CacheGetUsername function