Skip to content

perf (evaluate): fetchOpenbook appears to fetch the player page twice per loan — reuse the handshake's terminal body #23

Description

@JavaGT

Filed by the Account-2 read-only amplifier (2026-09-16, HEAD f635e62). Problem: fetchOpenbook follows the signed message handshake to set the listen cookie (src/openbook.mjs:302), then immediately issues an explicit GET / for the player page carrying window.eData (src/openbook.mjs:306-309). follow() already returns the terminal response body (src/openbook.mjs:396-406), and the e2e sim serves the player page at / with set-cookie on the first hit (test/helpers/overdrive-sim.mjs:166-171,195-201) — suggesting the handshake's terminal 200 already carries eData on real hosts too.

Impact if confirmed: one full RTT + one large page transfer wasted per loan on every archive/open. med confidence — the sim was written to match observed behavior, not proven; the real-host handshake terminal shape is unverified.

Evaluation question (implementation is NOT the todo): probe a real host once — capture the handshake's terminal body and check for eData. If present, reuse it with a fallback to the explicit GET (shape-guarded); if absent, close as declined with the probe evidence.

Proposed focus packet: one-shot probe script (existing session), shape guard in fetchOpenbook, decode-path unchanged.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions