Skip to content

Merge upstream QuantumNous/new-api into main (sync through 2b6f1dfef) - #9

Merged
chunfeng789 merged 22 commits into
mainfrom
merge/upstream-2026-08-30
Aug 30, 2026
Merged

Merge upstream QuantumNous/new-api into main (sync through 2b6f1dfef)#9
chunfeng789 merged 22 commits into
mainfrom
merge/upstream-2026-08-30

Conversation

@chunfeng789

Copy link
Copy Markdown
Owner

Agent

  • Tool: Claude Code
  • Tool version: CLI (Claude Agent SDK)
  • Model (full id): claude-opus-4-8
  • Host (CLI / IDE / GitHub coding agent / other): CLI
  • Date (UTC): 2026-08-30

This PR was AI-generated / AI-assisted. The current git user (Chunfeng <chunfeng.eee@gmail.com>) is not one of the repository's historical core developers.

Links

  • Closes #
  • Related: upstream QuantumNous/new-api main @ 2b6f1dfef (merged here)

This is a fork-maintenance sync PR: it merges the latest upstream QuantumNous/new-api main into this fork's main. It is not a feature contribution, so there is no issue to close.

User request

https://github.com/QuantumNous/new-api 最新代码合并到 https://github.com/chunfeng789/new-api
提交 pr 到 chunfeng789/new-api main

Out of scope — refuse

  • Matched: no
  • If yes, what was told to the user (stop here; do not open a PR): N/A — this is an upstream→fork sync of existing upstream code, none of the listed categories apply.

Kind

  • Bug fix
  • New feature
  • Performance / refactor
  • Docs
  • Other: Merge/sync latest upstream into the fork's main

Issue facts

Not applicable — this is a routine upstream sync, not a bug report. No linked issue.

  • Actual behavior: n/a (fork is behind upstream by 21 commits)
  • Impact: n/a
  • Frequency: n/a
  • Evidence that the problem is in new-api rather than the client or upstream: n/a
  • Applicable types and their fields (relay / billing / frontend / deployment): not applicable

Change

Merges 21 upstream commits (through 2b6f1dfef) into this fork's main via a merge commit, preserving the fork's 8 local customization commits. Notable upstream changes pulled in:

Five files conflicted and were resolved so the fork's customizations are preserved on top of upstream:

  • CLAUDE.md — kept upstream's mandatory "Read AGENTS.md" section and re-added the fork's "never PR to upstream; always --repo chunfeng789/new-api" rule under a Claude Code section.
  • README.md — kept the fork's Chinese README (Aliyun registry image registry.cn-hongkong.aliyuncs.com/...). Upstream contributed nothing to README outside the conflict block, so the fork copy is retained verbatim.
  • go.mod — unioned the fork's go-pay/* indirect deps (WeChat/Alipay native QR pay) with upstream's go-sourcemap/sourcemap + google/pprof, then reconciled with go mod tidy.
  • router/web-router.go — combined upstream's new SetWebRouter(..., pluginDispatcher gin.HandlerFunc) signature and its NoRoute(pluginDispatcher, middleware.RouteTag("web"), gzip, rateLimit, cache, static.Serve, fallback) chain with the fork's Cloudflare per-host Web Analytics token injection (injectedPages pre-render + cloudflareWebAnalyticsTokenForHost). The call site in router/main.go already passes pluginDispatcher; WebAssets retains the fork's CloudflareWebAnalyticsToken / CloudflareWebAnalyticsHostTokens fields, populated in main.go.
  • web/src/i18n/locales/_reports/_sync-report.json — accepted upstream's deletion (generated report produced by web/scripts/sync-i18n.mjs).

Research

Duplicate / prior art

  • Search queries (issues, PRs): n/a — not a feature; this is a direct upstream merge.
  • What already existed and why this is not a duplicate: the fork previously merged upstream at a81b2f8cf ("Merge branch 'QuantumNous:main' into main"); this continues that same sync workflow with the newer upstream main.

Docs and code

  • https://docs.newapi.ai/ : not consulted — no behavioral change is introduced by this fork beyond adopting upstream code that already ships with its own docs.
  • https://deepwiki.com/QuantumNous/new-api : not consulted — same reason.
  • README / repo docs: followed AGENTS.md / CLAUDE.md conflict-resolution and PR rules (target the fork, mark AI-assisted, use this template).
  • Code paths and what they imply for this change: router/web-router.go, router/main.go, main.go (web asset wiring + Cloudflare analytics), go.mod/go.sum (dependency union), and the upstream JS-plugin subsystem (pkg/jsplugin/, plugins/, controller/task_plugin*) which builds cleanly against the merged tree.

Alternatives considered

  • Option A: rebase the fork's 8 commits onto upstream main — rejected; it rewrites the fork's published history and loses the merge audit trail.
  • Option B: merge upstream into main (chosen) — preserves both histories and records the resolution in one merge commit.
  • Why this approach: standard fork-sync; keeps fork commits intact and makes the conflict resolution reviewable in one place.

Files

Path Why
CLAUDE.md Conflict: keep upstream mandatory-read + fork's no-upstream-PR rule
README.md Conflict: keep fork's Chinese README
go.mod / go.sum Conflict: union deps, go mod tidy reconcile
router/web-router.go Conflict: merge upstream pluginDispatcher chain + fork Cloudflare token injection
web/src/i18n/locales/_reports/_sync-report.json Conflict: accept upstream deletion (generated file)
(200+ other paths) Fast-forwarded upstream changes (JS plugin system, password encryption, billing/i18n updates, tests) — no manual edits

Behavior

  • Before: fork main at 2ca289aa, 21 commits behind upstream main.
  • After: fork main contains all upstream changes through 2b6f1dfef plus the fork's 8 customization commits; web routing serves the plugin dispatcher chain while still injecting the fork's per-host Cloudflare analytics token.
  • Explicit non-goals / leftover work: no new features authored here; no upstream behavior intentionally altered beyond conflict resolution.

Verification

  • Commands and results:
    • go build ./... — pass
    • cd relaykit && GOWORK=off go build ./... — pass (relaykit module independence per AGENTS.md)
    • go vet ./router/ — pass
    • go mod tidy — clean; fork go-pay/* and upstream deps both retained
    • cd web && bun install — installed upstream's new node-forge / @types/node-forge (and @codemirror/lang-javascript)
    • cd web && bun run typecheck (tsgo -b) — pass
  • Manual steps and observed result: verified SetWebRouter call site (router/main.go) passes pluginDispatcher; verified WebAssets Cloudflare fields still populated in main.go; confirmed zero leftover conflict markers in the tree.
  • UI: no screenshot — no UI was hand-modified; frontend changes are upstream's.
  • Tests added or updated: none authored; upstream's new tests are included as-is.
  • Databases / providers / platforms exercised: compile + typecheck only. Full DB/provider test matrix (SQLite/MySQL/PostgreSQL) not run.
  • Not verified: full backend go test ./..., frontend vitest, production rsbuild build, and runtime behavior of the merged upstream subsystems.

Risks

  • Failure modes: upstream JS-plugin task system and password-encryption changes are substantial; runtime behavior beyond compilation was not exercised here.
  • Billing / quota / auth impact: upstream includes billing (time-rule fix, task pricing) and auth (opt-in password encryption) changes; merged as-is, not independently re-audited in this PR.
  • Follow-ups: run full go test ./... + bun run test + a production build before shipping; smoke-test login (password encryption) and a task-plugin flow.

Scope check

  • Single focused change: yes — one upstream→fork merge commit with conflict resolutions.
  • Secrets included: no
  • Out of scope (Coding Plan / reverse-engineered channel / third-party wrapper / Codex): no

zcxads666 and others added 22 commits August 29, 2026 13:34
…#6987)

* fix(web): align admin binding types

Refs QuantumNous#6985

* test(web): restore animation mock
* fix(relay): return 400 for invalid request parameters
…in models

Channel model_mapping keys exposed in a channel's model list now act as
first-class aliases for task-plugin models across the whole line:

- Derived alias view (model/task_model_alias.go): built from enabled
  channels' model_mapping, chain-following with cycle detection, declared
  names always win, cross-plugin conflicts dropped. Rebuilt on channel
  cache refresh, registry generation change, and a 60s TTL.
- Request path: PinTaskPluginEndpoint resolves declared-name case folds
  and mapping aliases before endpoint lookup (never rewriting the body
  until the endpoint is claimed), pins with MappedModel, and the decode
  contract accepts alias echoes without loosening model ownership for
  normal pins. Legacy /v1/tasks submit folds case variants the same way.
  Fixes aliases on POST /v1/responses silently falling through to the
  main relay against task channels.
- Mapping order: ModelMappedHelper now runs before the plugin submit
  hook builds and caches the upstream body, so channel model_mapping
  actually reaches the upstream request. Plugins receive the mapped
  name as ctx.upstreamModel in both decode and submit contexts.
- Billing: identity stays the origin name; when the alias has no tiered
  expression, the selected channel's mapping tail expression applies.
  Pricing page and billing-expr smoke tests resolve aliases to the
  owning plugin's usage schema.
- Case folding: ASCII-only fold with exact-match priority; same-plugin
  and cross-plugin fold collisions rejected at registration.
- Plugins: model-keyed rate tables, req_key derivation, and combo
  validation in doubao/kling/jimeng/hailuo/vidu/sunoapi now key on
  ctx.upstreamModel || ctx.model; render/echo paths keep ctx.model.
…bility

GORM v1.25.2 closes cached prepared statements asynchronously on any SQL
error and immediately re-Parses the same deterministic name (pgx's
stmt_<sha256>) on the same client connection. Transaction-pooling proxies
(PgBouncer >=1.21 with max_prepared_statements, Neon, Supabase) respond
with FATAL "prepared statement name is already in use" (SQLSTATE 08P01)
and drop the connection. PreferSimpleProtocol only disables pgx's
implicit prepare and never covered GORM's explicit PrepareStmt cache.

- PostgreSQL now runs with PrepareStmt disabled entirely; named prepared
  statements are fundamentally session state and cannot be made safe
  under transaction pooling. Parse/plan cost is noise for this workload.
- Upgrade gorm to v1.25.12 so MySQL/SQLite statement caches (still
  enabled) no longer churn close/re-prepare on ordinary SQL errors;
  v1.25.9+ restricts eviction to driver.ErrBadConn. Deliberately not
  v1.26+, whose LRU eviction has an open use-after-close race (#7831).
- sanitizeDBError now attaches a remediation hint on 08P01/42P05 so
  affected deployments can self-diagnose from the log line.
Marketplace install/upgrade on a factory-served plugin actually created
a permanent override shadowing every future built-in release. The card
now shows an informational "Updates with the system" badge instead of
the action, while keeping the built-in vs marketplace version line and
the upgradable state badge visible. Deliberate overrides are untouched:
upload and marketplace actions on overridden or third-party plugins
behave as before, and the plugins table now hints when an override
lags behind the shipped built-in version so operators know deleting it
restores the newer factory plugin.
… stop concurrent write lockouts (QuantumNous#7030)

* fix(sqlite): enable WAL + working busy timeout + _txlock=immediate to stop concurrent write lockouts
…ocol

With PrepareStmt disabled, PostgreSQL queries run over pgx's simple
protocol, which encodes every []byte parameter as a bytea hex literal
('\x...'). driver.Valuer implementations returning []byte from
json.Marshal therefore fail json-column writes with SQLSTATE 22P02
(reported on the channels UPDATE path via ChannelInfo).

Reproduced against a live PostgreSQL 16: []byte Valuer into a json
column fails under simple protocol, string succeeds; []byte into a
text column silently stores the hex literal (no such path exists in
the repo today — audited all Valuers, json.RawMessage fields, and raw
SQL call sites).

- ChannelInfo, Properties, TaskPrivateData, JSONValue Value() now
  return string; zero-value nil semantics unchanged. Task.Data
  (bare json.RawMessage) is unaffected — database/sql's default
  converter already passes it as expected.
- Their Scan() counterparts now accept both []byte and string via a
  shared jsonScanBytes helper: SQLite returns string for these columns
  once Value() emits string, and the old []byte-only assertions
  silently zeroed the field (caught by the model test suite).
- Add regression tests locking both contracts: json-column Valuers
  must return string (or nil for zero values), Scanners must accept
  []byte and string.

Verified end-to-end against PostgreSQL 16 with the real model types:
Channel create/update/read-back, Task json fields, PrefillGroup items.
…nded heap growth → OOM) (QuantumNous#6949)

* fix(relay): bound the wait for upstream response headers (fixes unbounded heap growth)

The relay transport sets a dial timeout, a TLS handshake timeout and an expect-continue
timeout, but nothing bounds how long it waits for the upstream *response headers* after
the request has been written. An upstream that accepts the connection and then never
answers -- without sending FIN/RST, which is what happens when a NAT/firewall silently
drops the flow or the provider hangs -- parks the goroutine in
net/http.(*persistConn).roundTrip forever.

That goroutine keeps the whole request alive, which in practice means three copies of the
request body stay reachable for the lifetime of the process: the raw bytes from
io.ReadAll in CreateBodyStorageFromReader, the decoded messages held as json.RawMessage,
and the re-marshalled upstream body from common.Marshal. BodyStorageCleanup cannot help
here: it runs after c.Next() returns, and for these requests c.Next() never returns.

Measured on v1.0.0-rc.23 in production (see QuantumNous#6947 for the full evidence):

  - 23 goroutines stuck in persistConn.roundTrip on a single 40h-old instance,
    blocked between 353 and 1894 minutes (5.9h to 31.5h)
  - 96.9% of the live heap, sampled after a forced GC, attributable to those three
    body copies (HeapAlloc 892 MiB surviving three GC cycles; HeapObjects dropping
    30x while bytes dropped only 25%)
  - the live floor grows with uptime: 33.7 MiB at 0.1h, 89.2 at 13.8h, 510.0 at 40.1h,
    955.2 at 146.8h, OOMKilled at 172.9h -- same image, same config, same load

Doubling the memory limit and adding GOMEMLIMIT only moved the OOM from 132h to 172.9h.

RELAY_TIMEOUT (http.Client.Timeout) cannot be used for this: it covers the whole response
read and would cut legitimate long streaming calls, which is why it defaults to 0.
ResponseHeaderTimeout only bounds the wait for the headers; streaming after they arrive is
unaffected.

The default is deliberately generous. Non-streaming upstreams usually send the response
headers only once generation has finished, so the value has to leave room for a long
completion. 1800s is 12x shorter than the shortest hang observed here while leaving
several times the headroom a normal non-streaming request needs; 0 restores the previous
unbounded behaviour.

The assignment goes next to the other transport.* lines rather than inside the else
branch: newRelayHTTPTransport() normally takes the http.DefaultTransport.Clone() path,
and DefaultTransport does not set ResponseHeaderTimeout either.

This repo already sets ResponseHeaderTimeout on its other outbound transports
(controller/model_sync.go, controller/ratio_sync.go); the relay path appears to have
been missed.

Refs QuantumNous#6947. Likely also the root cause of QuantumNous#6731, which reported the same symptom
(production OOM on /v1/responses after ~64h) but was closed for template reasons.

* review: clamp overflowing timeout values and switch the test to testify

Addresses the two CodeRabbit findings on this PR.

Overflow (common/init.go:113): a RELAY_RESPONSE_HEADER_TIMEOUT beyond ~9.2e9 seconds
overflows time.Duration and can wrap into a *tiny positive* timeout, which would cut
every relay request instead of only the stuck ones. The value is now clamped before the
conversion, with regression tests for both the negative and the overflowing input.

I did not add fail-on-startup validation for negative values, for two reasons: the
existing `if seconds > 0` guard already treats them as "disabled", and the neighbouring
env-driven timeouts in this file are less strict still -- RelayIdleConnTimeout is
converted with no guard at all. Failing startup on a bad value would be a behaviour
change out of step with the rest of the file; happy to add it if you'd prefer that
direction repo-wide.

Test style: switched to testify (require.Equal / require.Zero / require.Positive), which
is what every other test under service/ uses.

go build, go vet and go test ./common/... ./service/... pass.
(`go build ./...` fails on the `web/dist` embed both with and without this change -- the
frontend bundle is not checked in.)
Merge 21 upstream commits (through 2b6f1df) into the fork. Highlights:
sandboxed JS task-plugin system, opt-in password login encryption,
relay 400 validation, SQLite WAL + busy timeout, upstream response
header timeout bound, and PG pooler/prepared-statement fixes.

Conflicts resolved:
- CLAUDE.md: kept upstream's mandatory Read-AGENTS.md section and
  re-added the fork's 'never PR to upstream' rule under Claude Code.
- README.md: kept the fork's Chinese README (Aliyun registry image).
- go.mod: unioned fork go-pay/* deps with upstream go-sourcemap/pprof;
  reconciled with 'go mod tidy'.
- router/web-router.go: combined upstream's NoRoute pluginDispatcher +
  RouteTag("web") chain with the fork's Cloudflare per-host analytics
  token injection.
- web/src/i18n/locales/_reports/_sync-report.json: accepted upstream
  deletion (generated report).

Verified: go build ./..., relaykit GOWORK=off go build ./...,
go vet ./router/, and web typecheck all pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@chunfeng789
chunfeng789 merged commit 609f052 into main Aug 30, 2026
2 checks passed
@chunfeng789
chunfeng789 deleted the merge/upstream-2026-08-30 branch August 30, 2026 17:03
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.