[v3] fix(runner): cache Microsoft profile/certificate fetches across bot connections - #72
Merged
Drownek merged 7 commits intoSep 6, 2026
Conversation
minecraft-protocol's built-in 'microsoft' auth refetches profile and certificates on every connect, no caching of their own. Every test gets its own bot connection, so a microsoft-auth account redoes that on every single test; enough tests in one run and one of those calls eventually hits a rate limit and fails a perfectly fine account. Add a custom auth function (microsoft-auth.ts) that mirrors minecraft-protocol's own microsoftAuth.authenticate but caches fetchProfile/fetchCertificates results per username for the life of the process. The access token itself is untouched — still fetched per connect via prismarine-auth's own disk cache, which is already cheap. Needs prismarine-auth as a direct dependency now (was only transitive through mineflayer) to call Authflow.getMinecraftJavaToken directly.
Session.createBot passed auth straight through as a string. Swap it for the cached custom auth function (microsoft-auth.ts) whenever the account is microsoft-auth; offline/mojang accounts are unaffected. Fixes Drownek#69
'import { Authflow, Titles } from prismarine-auth' compiled fine but
crashed at runtime: 'SyntaxError: The requested module prismarine-auth
does not provide an export named Titles'. prismarine-auth is CJS;
Node's cjs-module-lexer interop for named ESM imports of a CJS module
isn't reliable here — it missed Titles even though both are plain
properties of module.exports.
Import the default (the whole module.exports object) instead and
destructure from that — the default import always works for CJS
interop.
Verified locally: typecheck, build, then imported the compiled
dist/lib/microsoft-auth.js directly with node. Caught only in CI, not
by tsc, since this is a runtime ESM/CJS interop quirk typecheck can't
see; this package has no local e2e harness to catch it earlier.
Owner
I also removed "sentinel strategy" for RCON i previously introduced. When RCON response is >4096 bytes, some servers split it into multiple packets, which the sentinel catches. However, our E2E tests never hit this limit, making the sentinel practically useless while it was actively triggering the concurrent packet crash.
Merging, thanks |
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.
Related to #65/#68 — same test run, different bug. Later in a heavy run, tests started failing with
Failed to obtain profile data for <account>, does the account own minecraft?even though the account is fine.Root cause: every test gets its own bot connection (
Session.createBot→mineflayer.createBot), so amicrosoft-auth account redoes the full Microsoft handshake every single test.prismarine-authalready disk-caches the MS/Xbox token itself (Authflow.getMinecraftJavaToken'sverifyTokens()skips the network call when it's still valid), butfetchProfile()/fetchCertificates()run unconditionally on every connect with no caching of their own — straight toapi.minecraftservices.com. Enough tests back to back and one of those calls hits a rate limit or a transient blip.Fix: a custom
authfunction (microsoft-auth.ts) that mirrorsminecraft-protocol's ownmicrosoftAuth.authenticate(same defaults, same session/error shape) but caches the profile/certificates result per account username in memory, for the life of the run process, and only refetches them if that first fetch never succeeded. Access token is untouched — still requested every connect, since that part is already cheap.Only the Microsoft handshake is affected.
mineflayer.createBot()still runs fresh per test, so this doesn't reopen #53.prismarine-authmoves from a transitive to a direct dependency of@plugwright/runner, since the custom auth function callsAuthflow.getMinecraftJavaTokendirectly.Verified with
npm run typecheck; the package has no unit test suite to add a test to.Fixes #69