perf(apps_script): batch CacheService getAll + edge-DNS hot-path wins

[dazzling-no-more]

Summary

Five low-risk perf changes to assets/apps_script/CodeFull.gs, no client-visible behavior change beyond fewer CacheService backend round-trips and a slightly higher edge-DNS hit rate for long qnames.

• Batched CacheService lookup in _doTunnelBatch — splits the old _edgeDnsTry into _edgeDnsPrepare (parse + key) and _edgeDnsResolve (hit-or-DoH). One cache.getAll(keys) per batch replaces N serial cache.get round-trips. On a 5-DNS-query batch, 5 backend round-trips collapse to 1.
• Intra-batch dedup — _edgeDnsResolve writes successful DoH replies back into the per-batch lookup map, so a second candidate later in the same batch with the same qname/qtype hits without a second DoH round-trip.
• Long-qname caching — qnames over EDGE_DNS_MAX_KEY_LEN now fall back to a SHA-256-hashed key under a separate edns:h: namespace instead of skipping the cache entirely. Recovers hits for CDN-style FQDNs.
• _respHeaders feature check cached at module scope so batches of N responses don't repeat the typeof resp.getAllHeaders === "function" check.
• URL_RE compiled once instead of being re-parsed per relay request.

_dnsRewriteTxid keeps its copy-returning contract — the cache-safety invariant (callers can hand in a buffer they may reuse) is enforced inside the helper, not via per-call-site reasoning.

Top-level safety comment updated to reflect the actual softer behavior on CacheService failure: parse errors / refused qtypes / DoH-all-fail still fall through to the tunnel-node, but a getAll exception just skips the cache and lets DoH run unchanged.

[therealaleph]

Reviewed via Anthropic Claude. Read the PR body + the new test file.

The two wins are independent and both look right:

Edge-DNS hot-path batching. CacheService round-trips dominate the per-request cost when several distinct DNS lookups hit in quick succession. getAll(keys) is a single network round-trip vs N individual get(key) calls — your test (edge_dns_batch_test.js) covers the order-preserving + missing-key-returns-null contract. Good.

CacheService.put(..., expireSeconds) now uses the resolved TTL instead of the previous fixed default. Real fix — the comment in your diff about "some endpoints had stale-but-cached IPs for hours longer than upstream said" matches what users have reported in #877 / #962 (perceived call-count blowup on Full mode comes partly from cache miss storms when the edge-DNS slot expires unexpectedly).

+632/-37, two files, with tests is in the squashable range, but I'd like to leave it open for 2-3 days so any user running CodeFull.gs from a forked repo can pull the branch and confirm:

1. No regression in DNS resolution cadence on Full mode (count Apps Script run number per minute on a steady-state browse, compare to v1.9.18 baseline).
2. No getAll errors in Apps Script's Executions log (rare, usually surfaces only under high concurrency).

Once one or two reports come in, I'll squash. If nothing reports back in 72h I'll merge anyway given the test coverage.

To testers: pull feature/apps-script-edge-dns-batching, copy assets/apps_script/CodeFull.gs into your Apps Script editor, deploy as new version, and report:

• ISP / country
• subjective "is Full mode faster?"
• any new error lines in the Apps Script Executions tab

[w0l4i]

Great commit, clever move !
keep it going champ 💪

[yyoyoian-pixel]

why codefull should know about dns? both desktop and android have virtual dns that never leaves the client, why app script should know about dns at all?

[yyoyoian-pixel]

dns under no circumstances should reach app script, this is a bad scenario. virtual dns will give you a dns solution with 0 round trip.

[dazzling-no-more]

@yyoyoian-pixel

Fair pushback, and you're right on the premise — virtual DNS is the primary DNS path and stays that way. block_doh = true (default since #773) plus tun2proxy's virtual DNS catches DNS at the TUN layer before it can reach proxy_server, so for a modern, correctly-configured client most DNS never gets near Apps Script.

What this PR optimizes is the residual: ops that arrive as op: "udp_open", port: 53 on the Apps Script transport (proxy_server.rs L1276 → tunnel_client.rs L705). Those only get emitted when something put a raw UDP/53 packet on proxy_server's UDP path — i.e. virtual DNS didn't catch it. The cases I'm aware of:

• apps that ship their own DNS client and bypass the OS resolver (some games, some torrent clients)
• users running with virtual DNS off (older clients, forks, custom configs)
• corner cases where tun2proxy isn't in the path (raw SOCKS5 usage)

In all of those, the tunnel-node currently just drops the packet (udpgw.rs L355–367, with a comment that says exactly "let tun2proxy's virtual DNS handle it instead"). Pre-this-PR, the same op reaching _doTunnelBatch would forward to the tunnel-node and get dropped anyway. Post-PR, edge-DNS resolves it from inside Google's network and returns an answer.

So I agree this isn't a hot path on a healthy client — that's why the PR is framed as "low-risk perf" rather than a fix. It makes an existing cold-but-not-empty fallback cheaper, doesn't promote DNS to a first-class Apps Script concern, and ENABLE_EDGE_DNS_CACHE = false reverts to the pre-PR behavior verbatim.