* 🤖 chore(auto-submit): Add generador-examenes (#185)

* 🤖 chore(auto-submit): Generate i18n for generador-examenes (#185)

Regression of lobehub#11905 - fix was reverted during base-ui migration (lobehub#12587)

Changed showInfoTag (implicit true) back to showInfoTag={false} (explicit false)
to prevent React Error lobehub#185 when clicking model selection dropdown in onboarding.

File: src/features/ModelSelect/index.tsx
Line: 131

PR lobehub#12587 inadvertently reverted the fix from lobehub#11905 by changing
showInfoTag={false} back to showInfoTag (implicit true).

This causes React Error lobehub#185 when clicking model selection dropdown
during onboarding.

Restores showInfoTag={false} to prevent the crash.

Fixes lobehub#12817

PR lobehub#12587 inadvertently reverted the fix from lobehub#11905.
This causes React Error lobehub#185 when clicking model selection dropdown.

Fixes lobehub#12817

PR lobehub#12587 inadvertently reverted the fix from lobehub#11905.
This causes React Error lobehub#185 when clicking model selection dropdown.

Fixes lobehub#12817

根据 PR lobehub#185 的代码审查建议，修复以下问题：

**Critical 修复**:
- 🔴 修复 Stream reader 资源泄漏
  - 在错误路径中添加 `await reader.cancel()` 防止内存泄漏
  - 确保在异常情况下正确释放资源

**High 修复**:
- 🟠 添加日志记录
  - 为 chunk 解析失败添加 warn 级别日志
  - 记录跳过的 chunk 数量和错误详情
  - 添加流式响应解析完成的 info 日志

- 🟠 改进 SSE 检测逻辑
  - 使用正则表达式替代字符串匹配
  - 提高检测的健壮性，避免误判

- 🟠 增强类型安全
  - 在类型转换前添加运行时类型守卫
  - 为空数组情况添加默认值处理
  - 确保不会创建无效的响应对象

**改进点**:
- 统一错误处理模式
- 提高代码可维护性
- 增强调试能力

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

fix:修复 Codex API 测试参数兼容性问题与增加支持流式测试

…e render loop (#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes #14650

…infinite render loop (lobehub#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
lobehub#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes lobehub#14650

…infinite render loop (lobehub#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
lobehub#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes lobehub#14650

…infinite render loop (lobehub#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
lobehub#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes lobehub#14650

…e render loop (#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes #14650

…infinite render loop (lobehub#14689)

Migrate all ScrollShadow usages to ScrollArea (scrollFade) to eliminate
the effect → setState → render → effect cycle that caused React error
lobehub#185 (Maximum update depth exceeded) in the scroll overflow hook.

Affected components:
- StreamingMarkdown
- AgentCouncil AutoScrollShadow
- AssistantGroup ContentBlocksScroll
- Conversation Thinking

Fixes lobehub#14650

…on YK return-url

User reported crash on /?payment=success after returning from YooKassa
hosted form. Stack trace: 'Minified React error lobehub#185 — Maximum update
depth exceeded'. Root cause not yet pinned to a specific render hook
in RetryModal — needs proper debugging with non-minified build.

Safety hotfix: comment out the mount so signed-in users can navigate
again. Bot DM recovery (Telegram side, cron-driven) is unaffected and
remains the primary recovery channel; only the on-site modal is gone
temporarily.

Will diagnose offline and re-mount once the loop is fixed.

…ryFor=

`utils.subscription.getBillingState` was in the useEffect deps array.
tRPC's useUtils() returns a stable outer object, but each `utils.X.Y`
descendant access goes through a Proxy that returns a NEW object
reference every render. React's deps comparison saw a "change" every
render, fired the effect every render, called setRetryAttempts(n+1),
re-rendered, fired again, ... → "Maximum update depth exceeded".

This was triggered any time a user returned from the YooKassa form to
/settings/plans?recoveryFor=<id> while the original payment was still
in 'pending' status (waiting for webhook). Started happening since
commit ef2291c (2026-05-17 "feat(billing): tie recovery flow to
YooKassa return_url") — was a latent bug for 5 days before today's
report.

Fix: omit `utils.subscription.getBillingState` from the deps array
(eslint-disable). The effect calls invalidate() once — it doesn't
need to re-run when the utils proxy reference shifts. Standard tRPC
pattern (see trpc.io docs for useUtils).

Also restore the RetryModal mount in (main)/_layout — the temp unmount
yesterday was unnecessary, the modal is unrelated to this crash.

…llation

Previous commit's fix (removing utils proxy from deps) was directionally
correct but addressed a non-existent issue. The actual bug is logical:

1. recoveryForId set from URL, recoveryPollEnabled=false initially.
2. Effect runs: hits "Start polling on first mount" branch →
   setRecoveryPollEnabled(true), setRetryAttempts(0).
3. Polling fetches redirectedPayment, status='pending' (webhook lag).
4. Effect runs 7× incrementing retryAttempts to 7.
5. retryAttempts === 7 → setRecoveryPollEnabled(false), setRecoveryOpen(true).
6. Next render: effect runs again. recoveryForId is STILL SET.
   recoveryPollEnabled is false → falls into "Start polling on first
   mount" branch → setRecoveryPollEnabled(true), setRetryAttempts(0).
7. Polling re-enabled, retryAttempts resets, back to step 4. ∞ loop.

Fix: on terminal branches (timeout / canceled / failed), ALSO call
setRecoveryForId(null). The URL param clears, the effect's first guard
`if (!recoveryForId) return` fires next time, no auto-restart.

This is the real fix. The user was hitting it any time they returned
from YK while payment was still in pending state (webhook hadn't
landed yet — common for the first few seconds).

Three previous attempts at fixing React lobehub#185 on /settings/plans?recoveryFor=
all addressed wrong symptoms. This is the actual race condition:

  1. retryAttempts hits 7 → terminal branch fires:
     - setRecoveryPollEnabled(false)
     - setRecoveryForId(null)
  2. setRecoveryForId(null) goes through nuqs's useQueryState which
     queues a router.replace() asynchronously. Several React renders
     can pass before `recoveryForId` reads as null.
  3. In those interim renders: recoveryForId still 'abc', but
     recoveryPollEnabled now false.
  4. Effect re-runs (deps changed), reaches the "Start polling on first
     mount" branch (`if (!recoveryPollEnabled)` is true) → resets
     retryAttempts to 0 and re-enables polling.
  5. Polling restarts, retryAttempts climbs 1→7 again, terminal fires
     again, async-set recoveryForId never sticks → infinite oscillation
     → React detects "Maximum update depth exceeded" → lobehub#185.

Fix: gate the reset branch with `retryAttempts === 0`. The reset branch
should only fire on true initial mount; after the first poll cycle
starts, retryAttempts is non-zero forever (within this URL-flow
session), so the reset branch can never re-enter mid-flow.

Also removed the `setRetryAttempts(0)` from the reset branch — it's
redundant when we know retryAttempts is already 0 (the new guard).