- Fix 7 stale comments still mentioning "限制检查" in handlers/services
- Make billingModelForRestriction explicitly list channel_mapped case
- Add slog.Warn for error swallowing in ResolveChannelMapping and
needsUpstreamChannelRestrictionCheck
- Document sticky session upstream check exemption
Move the model pricing restriction check from 8 handler entry points
to the account scheduling phase (SelectAccountForModelWithExclusions /
SelectAccountWithLoadAwareness), aligning restriction with billing:
- requested: check original request model against pricing list
- channel_mapped: check channel-mapped model against pricing list
- upstream: per-account check using account-mapped model
Handler layer now only resolves channel mapping (no restriction).
Scheduling layer performs pre-check for requested/channel_mapped,
and per-account filtering for upstream billing source.
Legacy instances created the settings table via ent auto-migration,
which emits Go-level defaults only. Migration 005 uses CREATE TABLE
IF NOT EXISTS, so the missing SQL DEFAULT was never backfilled. This
caused 098's raw INSERT to fail with a NOT NULL violation on
updated_at. The new migration is idempotent and safe for fresh
installs (no-op) and historical instances (backfills the default).
Two issues fixed:
1. Alipay.SupportedTypes() returned ["alipay_direct"] and Wxpay returned
["wxpay_direct"], but the frontend sends payment_type="alipay"/"wxpay".
The registry lookup failed with "payment method (alipay) is not
configured". Fix: return the base types ["alipay"]/["wxpay"].
2. When multiple providers support the same payment type (e.g. EasyPay
and Alipay direct both handle "alipay"), only the last-registered
provider's instances were reachable — the registry mapped one type to
one provider key, and SelectInstance queried by that single key.
Fix: bypass the registry in invokeProvider and let SelectInstance
query across all providers when providerKey is empty. The selected
instance's own ProviderKey (now included in InstanceSelection) is
used to create the correct provider, enabling true cross-provider
load balancing.
Closes#1592
When an Anthropic API key's credit balance is depleted, the upstream
returns HTTP 400 with message containing "credit balance". Previously,
the 400 handler only checked for "organization has been disabled",
so credit-exhausted accounts kept being scheduled — every request
returned the same error.
Treat this case identically to 402 (Payment Required): call
handleAuthError → SetError to stop scheduling the account until
an admin manually recovers it after topping up credits.
Closes#1586
- Add docs/PAYMENT.md and docs/PAYMENT_CN.md with full payment setup guide
- Mark Sub2ApiPay as deprecated in ecosystem tables (payment is now built-in)
- Add built-in payment system to features list in all 3 READMEs
Upstream removed sora feature (090_drop_sora.sql) but left i18n keys
and wire.go references. Clean up:
- Remove entire sora i18n block from en.ts and zh.ts (~190 lines)
- Remove sora nav key and unused 'data' settings tab key
- Remove sora_client_enabled from settings (fork-specific)
- Remove SoraMediaCleanupService from wire.go
The API client's error interceptor was dropping the reason and metadata
fields from backend error responses. This caused PaymentView to miss
specific error codes (TOO_MANY_PENDING, CANCEL_RATE_LIMITED) and fall
back to generic error messages.
Stripe payment path was setting expiresAt to empty string, causing
PaymentStatusPanel to fall back to hardcoded 30-minute default when
the popup redirect switches to the waiting view.
