* gateway tests: the quiet mid-reply tests wait for, and count, the keepalive after the vendor's first words, as a held stream's before them is the agent's too (TestQuietStreamMidReplyKeptAlive failed once on main at GOMAXPROCS=2, load ~30)
The failing body began ": keepalive" before the role chunk and "hel".
That ordering is allowed, not a bug: quietFast lets watch keep the agent
alive 40ms into the try, and a vendor slow to answer (status 0, nothing
held) or one that flushed response.created and paused before "hel" (only
the role chunk, a lead, held) gets the held stream's keepalive first, as
TestSilentHeldStreamKeptAlive requires. Content that reaches the
holdWriter is scanned and flowed under h.mu, which keepQuiet and
keepAlive take, so no keepalive goes out after content the writer has
and before it is relayed. A vendor delayed 150ms before its first bytes,
or between response.created and "hel", gives the failing body every
time, with the keepalive sent at status 0 or with only the role chunk
held.
The tests released the vendor at the first keepalive and required "hel"
before it, so a slow first write made them fail, or test the held path
instead of the mid-reply one. readQuiet now releases the vendor at the
first keepalive after the given text, and aliveAfter asserts a keepalive
between "hel" and "lo": TestQuietStreamMidReplyKeptAlive and
TestQuietStreamsKeptAliveEveryProtocol's mid-reply cases.
TestQuietKeptAliveOnlySoLong counts only the keepalives after "hel", as
the held ones before them have their own 200ms. The every-protocol check
matches `"lo"` quoted: bare, it matched the anthropic cases'
content_block.
With a 150ms vendor delay injected, the old assertions fail all 5
mid-reply cases and the new ones pass. With keepQuiet's passing-branch
keepalive removed, all 6 mid-reply tests fail, delay or not. go vet;
go test -tags nogui -race -count=20 -run
'TestQuietStream|TestSilentHeld|TestQuietKeptAliveOnlySoLong'
./internal/gateway; the whole package with go test, and as a prebuilt
binary at GOMAXPROCS=2 three times (load 18-28), all pass.
* gateway tests: TestTranslatedStreamKeepsClientAlive stops counting the client's idle timeout once it has the reply's last event (red on ubuntu CI at ef5fba2c, run 37471004500: responses_to_chat "idle_timeout=true completed=true") — the gateway writes and flushes finish_reason, usage and data: [DONE] back to back in chatEncoder.finish, then serve's bookkeeping (NoteServed, saveSticks, usage.Append) runs before the handler returns and net/http sends the stream's close. On a loaded runner that, or the test's own goroutine being held, passed the 150 ms the test still counted after [DONE]. No client's idle timeout counts that wait: Codex hangs up on response.completed, and the clients that read on to the close give minutes. Chat's marker is now data: [DONE], the stream's last event, instead of finish_reason two events before it. With a 200 ms sleep after enc.finish() on the Chat path, the old test fails 20 of 20 exactly as CI did and the new one passes 20 of 20. The new test still fails 20 of 20 with the sleep before enc.finish() (completed=false), with readSSEAlive's keepalives taken out (#436), and with the Chat keepalive followed by a blank line again ("events with no data"). go test -race -count=20 -run '^TestTranslatedStreamKeepsClientAlive$' ./internal/gateway, go vet and go test -tags nogui ./... pass.
* plugin tests: the fake plugin's windows renew at times set when the host loads it, so the gateway's TestPluginFailover passes when an hour begins between two readings of an account's usage (waitingsnow)
The fake plugin told each account's five hours to renew an hour after
its usage was read, and its week a day after. TestPluginFailover weighs
the accounts by what the plugin tells (provider.Allowances), and Smart
routing puts first the account whose week renews sooner, to the hour;
accounts alike keep their order. A request that fails on an account's
quota, or in its stream, drops that account's reading
(staleAllowance), and the next request reads it again. A 401, as in
the gone round, is failOther and drops nothing (rest,
gateway/routing.go). When an hour began between a@fake's read after
the quota round and its read after the stream round, a@fake's week
renewed in the hour after b@fake's. b@fake then went first in the gone
round, failed with a 401 and kept its first reading, so the request
with both out was tried as b, a, full, which fails the test at
plugin_failover_test.go:210. An hour that began after the first
readings but before a@fake's read after the quota round put b@fake
first in the stream round instead, which failed b@fake and read it
again too, and the test passed.
The test fails every time an hour begins between those two reads of
a@fake, and passes otherwise: the 8 such runs below failed and the
other 13 passed. The reads are 12 to 76ms apart in the runs below
without the hold, and a reviewer's -race build measured 33 to 106ms in
6 runs, so a run at a random time fails about once in 34,000 to
300,000. CI's Linux job installs bun 1.4.2 and runs the test in its
Test and Race steps. Found by a review of the tests that compare
renewals to the hour; no CI run was checked for it.
The windows now renew an hour and a day after born, when the host
loaded the plugin, however often an account is read, as a vendor's
windows renew at times of their own. Run once in a process, as CI's
Test and Race steps run it, TestPluginFailover reads its accounts from
the one host started after its plugin.Add, so they renew together. Run
again in one process (-count), a run can still weigh an account by the
previous run's host, born perhaps in the hour before, until that
account fails and is read again: provider's allowances and usage
readings outlive fresh(t) and plugin.Settle. That account then goes
first, and the test's rounds fail it and read it again before the
checks that depend on order, so it still passes; clearing those caches
is left for its own commit.
TestPluginUsage now reads a@fake's card a second time from its refresh
button, 2ms later, and wants each window to renew when it did the first
time, as a vendor's do. That is the check that fails without this
change. Its other bounds (the five hours in 50 minutes or more, the
week in 23 to 25 hours, full@fake's five hours used up) hold while the
host is under 10 minutes old; no other test reads these times.
Verified under a temporary HOME with Go's caches pinned, every test run
with -tags nogui and bun 1.4.2. With 01aaa8e9's index.js put back,
TestPluginUsage fails every run:
plugin_usage_test.go:109: a@fake's 5 hours renews at 2026-10-07
12:16:35.567 +0000 UTC read again, at 2026-10-07 12:16:35.539 +0000
UTC first
and with this one it passes, also with -count=5.
With 01aaa8e9's index.js, TestPluginFailover passes unless an hour
begins between those two reads. failgap.sh, a scratch script, builds
the gateway's test binary once and runs TestPluginFailover with the
old plugin and with this one. It makes the plugin's usage hook tell
its windows from Date.now() plus a shift, set at the first reading so
that an hour begins a set time later (Go's clock is left alone), and
logs each reading. Its copy of the test can hold 2s before the stream
round, which puts its lines 5 further down. With the hour 30ms after
the first reading, the old plugin failed 3 runs of 3, its two reads of
a@fake either side of the hour (at 23 and 42ms, 20 and 34, 18 and 37):
plugin_failover_test.go:215: fake-claude with the others out: 200
{...} (tried [b a full])
At 45ms it failed 1 of 3 (44 and 69ms). At 60, 80 and 120ms it passed
9 of 9, a@fake read twice before the hour, or once after it and b@fake
read again. Held 2s before the stream round, with the hour 50 or
1100ms after the first reading, it failed 4 of 4 (a@fake read at 24 to
34ms and 2044 to 2121ms). This plugin passed all 19 of those runs.
That shows only that the test passes with it: its windows are fixed
from born when the host loads it, before failgap's first reading moves
the clock, so the moved hour never reaches them. Held 2s with the hour
30 minutes away, both plugins passed 2 of 2. born.sh, run as a process
per run, logged the host and the born behind each of the plugin's
reads in 20 more runs of this one: 9 a run, each run's from one host
and one born. It logs the plugin's reads, not what routing weighed.
gofmt -l internal/provider/plugin_usage_test.go prints nothing. go vet
./..., go build ./..., GOOS=linux go build -tags nogui ./...,
GOOS=windows go build ./... and GOOS=windows go vet -tags nogui
./internal/provider/ pass. go test -tags nogui ./... passes, 43
packages ok, with bun 1.4.2 on PATH, and so do TestPluginFailover and
TestPluginUsage* with -race -count=20.
* gateway tests: TestTranslatedStreamKeepsClientAlive fails when the stream doesn't close within 5s of its last event, rather than waiting on it with no limit
After the reply's last event the read had no time limit, so a gateway
that never closed the stream would hang the test until the package
timeout (yetone on #1163). The idle timeout still stops at the last
event; a 5s limit on the close follows it.
TestPluginFailover failed about 1 run in 90 at "a refused isn't marked".
With notePluginLapse logged, a failing run read: a background reading of
a's allowance (loginReading, after the "stream" round's StaleAllowance)
began at 31.985; the upstream answered a's request 401 at 32.001 and
notePluginSaid marked a lapsed at 32.003; the reading ended clean at
32.011 and notePluginLapse(200) took the mark off; the test read the
logins at 32.042. Users meet the same: a reading of the Usage page or of
routing's allowances that is out when a request is refused clears the
mark the refusal left, and routing goes on trying the refused account;
one that ends refused marks an account a request has just gone through
on.
What plugin accounts' sign-ins are told of is now counted under
loginsMu (pluginSignInTold, pluginSignInSaid). A request's answer, a
sign-in and the plugin's own signIn events are told now and apply as
before. pluginLoginQuota takes the count before plugin.AccountUsage, and
what its reading found applies only when nothing was told of that
account since (notePluginLapseSince), as Allowances leaves out an
account renewed while it read. A count rather than a time: Windows'
clock moves in ticks of up to 15.6ms, and a reading begun just after an
answer would read as begun with it.
TestPluginUsageReadOlderThanAnswer holds the fake plugin's usage on an
httptest server ($FAKE_USAGE, whose 401 the fake now reads as an expired
sign-in) while a request's answer is noted, both ways, and checks that
readings begun afterwards still mark and clear. Each direction fails
without the fix. TestPluginFailover now reads the allowances the
"stream" round left stale before the "gone" round: the fake's usage
doesn't ask the upstream that refuses, so a reading that asks after the
401 finds the sign-in good and rightly takes the mark off. A review
reproduced that with a delay injected before the count is taken.
Left as it is: a reading whose own renewal of the token tells "renewed"
before it asks skips the "expired" it then finds; the next 401 marks the
account. Not tried with a real plugin account.
Under a temp HOME with Go's caches pinned and bun 1.4.2: gofmt, go vet
-tags nogui ./..., builds for darwin, GOOS=linux -tags nogui and
GOOS=windows (and windows vet of provider and gateway) pass; go test
-tags nogui ./... passes; the changed provider tests and
TestPluginSaysSignIn/TestPluginFailover pass with -race -count=20; the
report's `go test -tags nogui -race -cpu 1,2,4 -count=30 -run
'^TestPluginFailover$' ./internal/gateway/` passed 3 rounds (270 runs),
where it failed 3 of about 54 runs before the fix on the same loaded
machine.
GitHub's search for topic:magpie-plugin (not archived, not a fork, not
magpie-community's own, which the market lists) is asked at most every six
hours and kept on disk, so a restart or GitHub being down shows what it said
last. Each repository is read from its package.json on the default branch.
When npm has that package published from the same repository, it is
installed from npm, because a repository often builds its dist only to
publish and Bun runs no build for a git install. Otherwise it is installed as
github:owner/repo, and only if the file it loads (exports, main or
magpie.middleware) is in the repository. Its page warns that it is
unofficial, says whether npm or the repository is what gets installed, and
shows the repository's README until it is installed. MAGPIE_PLUGIN_MARKET=off
asks GitHub nothing.
Checked against real GitHub with the topic set to opencode-plugin in a
sandbox: 43 repositories came back, and 32 were kept (30 from npm, 2 from
git). github:ndom91/open-plan-annotator, one of the git ones, really
installed and loaded. alfaoz/opencode-see-image, whose dist isn't in its
repository, failed to load before the entry check and is now left out. The
test fixtures are GitHub's and npm's real answers.
Ran: go test -race -count=3 ./internal/plugin, go test ./internal/gui, go
vet, and plugin-github.test.cjs (Chromium and WebKit, 980/440, en/zh/ja/de,
18/18). The full GUI suite passed 3343 of 3348. The 5 failures were WebKit
number-units, purpose-filter and routing-failed-open, which pass 3/3 on
their own and don't touch the Plugins page.
The built-in sign-ins that come back to a port on this machine (Codex,
ChatGPT API, Devin, Kiro, Zed, Gemini, Antigravity) already took the
pasted address. Their plugins didn't: a subscription moved onto its plugin
(Devin, Kiro, Zed) or a plugin's own browser sign-in (Trae) showed only
"the account shows up here as soon as you're done", and a browser on
another computer than magpie's ended on a page that won't load with no way
to finish.
Now a plugin's "auto" sign-in whose page names a port on this machine to
come back to (redirect_uri, auth_callback_url, callback on localhost, or
Zed's native_app_port: loopbackPorts) sets pasteCallback, so the GUI shows
the same Callback URL field as the built-ins, and `magpie plugin login` /
`magpie accounts add` ask for it too. SubmitSignInCallback opens the pasted
address on 127.0.0.1 at that port, never through a proxy, so the plugin's
own listener finishes the sign-in as it would for the browser; an address
on another port or host is refused, a page that sends the browser on to a
page that comes back to the same port (Kiro's AWS sign-in) becomes the next
page to open. Command Code's page posts its key from script, which leaves
no address to paste, so it keeps offering the plugin's API key way.
Verified: TestPluginSignInTakesAPastedCallback (fake plugin with a loopback
sign-in, $FAKE_LOOPBACK) fails without the wiring in pluginBegin ("a
sign-in that comes back to a port here takes no pasted address:
{... PasteCallback:false ...}") and passes with it, -race -count=10;
TestLoopbackPorts covers the community plugins' page addresses.
go test -race ./internal/provider ./internal/plugin and the root package's
Plugin|Login|SignIn tests pass; vet, gofmt, darwin/linux nogui/windows
builds pass. With the real community Devin, Zed and Kiro plugins in a
sandbox HOME, each sign-in offered the field and a pasted address reached
the plugin's listener and the vendor (bogus code refused by Devin 401, Zed
"couldn't be decrypted", Kiro 400). signin-paste-plugin.test.cjs (new),
signin-callback and signin-paste-codex pass in Chromium and WebKit, en and
zh, at 360px; no new strings. Not tried: a real successful sign-in from a
browser on another computer.
The Grok plugin's sign-in said only "grok login gave no link to open".
The plugin host has magpie's proxy only as MAGPIE_*_PROXY, so the
`grok login` the plugin runs went out with none, where the built-in's had
it (netproxy.Env); where x.ai is reached only through a proxy, it failed.
host.js's spawn wrapper now gives a started program HTTPS_PROXY and
HTTP_PROXY (the account's own proxy, none for direct, else magpie's) when
the plugin set none.
grok 1.0.46, unable to reach x.ai, prints "Error: error sending request
for url (https://auth.x.ai/oauth2/device/code): …", whose URL the
built-in's runCLISignIn took for the page to open; a line saying error
gives no link, and a login with none ends with the CLI's last line. The
plugin does the same from 0.1.8, which the grok mover now asks for.
plugin_cliproxy_test.go and TestCLISignInSaysWhyNoLink fail before this.
Checked with grok 1.0.46 itself through the plugin host and the published
plugin's code, given a proxy that refuses: the CLI goes through it and the
error names what it said.
Moody-Sin: the Routing page showed a WorkBuddy account as "已用 71%" only, which for a plan counted in credits says little. A quota window now carries its own count when the vendor counts in amounts — amount of limit, in unit (QuotaWindow, QuotaSpan for quota --json and /v1/magpie/quotas, and the routing trace's Weighed, from the window its share is of: Allowance.Count). WorkBuddy's built-in fills it from the resource summary, and @magpie-community/opencode-workbuddy-auth 0.1.8 tells it from auth.usage (amount / limit / unit, passed through host.js); the workbuddy mover's min is 0.1.8. The Routing page's stage and its list of what each account did, the Usage page's meter, the menu bar's tooltip and the TUI say "3,550 / 5,000 credits · 71% used", or "1,450 / 5,000 credits · 29% left" with Left on (积分 in Chinese); a window counted in shares alone reads as before.
quota-credits.test.cjs (WebKit, en/zh, used/left, Routing and Usage pages) fails on the old assets and passes; TestQuotaWindowCount, TestAllowanceCount, TestTraceTellsTheCount, TestPluginUsage (the count through the host) and TestWorkBuddyAccounts cover the Go side. Tried with the real WorkBuddy and WorkBuddy AI accounts in a sandbox magpie: moved onto the local plugin, /api/usage/quotas gives 33.29 / 3900 and 13.47 / 2250 credits and the Usage page reads "33.29 / 3,900 积分 · 已用 0.9%", "3,866.71 / 3,900 积分 · 剩余 99.1%" after a click on the count; not moved, the built-in gives the same for WorkBuddy. The Routing page with two real accounts of one provider wasn't tried (one account each). go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.
forever