geo: fix cross-surface cache inconsistency and 3 non-responsive answer pages - #1610
Merged
Conversation
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
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.
What
5 targeted fixes for the GEO issues identified in the audit.
Changes
Cache consistency (root cause of cross-surface value discrepancy)
revalidate-aggregate/route.ts: when the worker publishes a new snapshot and POSTs to this endpoint, it now also callsrevalidateTag("benchmarks", "default")in addition torevalidateTag("bench-aggregate"). Previously the per-bench caches (bench-unfiltered-v51, used by/answers/[slug]detail pages) were only refreshed by their 300s TTL clock, while aggregate surfaces (llms.txt, /api/citable, /answers hub) refreshed immediately on worker publish. Result: different values between the hub card and the detail page for up to 5 minutes after each worker cycle.llms.txt: add date anchor to headline claims
headlineSentence(b)withgroundingTraceLine(b, SITE.url)— the existing helper that already prependsAs of {isoDate}, ... Source: OpenChainBench, {url}. LLMs caching llms.txt for weeks now cite a time-stamped claim instead of a bare number that perimés silently.Answer YAML: pm-rate-limits (metric/question mismatch)
which-prediction-market-has-the-strictest-rate-limits.yml:{{best_name}}resolves to the provider with the lowest warm-book p50 (latency), not the strictest rate limit. Myriad has the tightest documented limit (30 req/10s); Polymarket queues via Cloudflare (no 429); Kalshi has a token bucket. Rewroteshort_answerandseo_descriptionto answer the actual question.Answer YAML: pm-data-freshness (circular answer)
which-prediction-market-data-api-is-the-freshest.yml: Polymarket's own gateway has a hardcoded p50 of 0.5ms (T0 anchor), so{{best_name}}always resolves to "Polymarket" → "Polymarket relays Polymarket data fastest" (circular). Rewroteshort_answerto name Polymarket as the T0 reference, then cite Codex via{{p50:codex}}(the actual third-party provider metric) andseo_descriptionaccordingly.Answer YAML: drpc-vs-publicnode-vs-1rpc (non-responsive hub preview)
drpc-vs-publicnode-vs-1rpc.yml:short_answerled with "Binance, Base, Avalanche" before naming any of the three queried providers. On the /answers hub, the 2-line preview showed "Binance" as the answer to a question about dRPC vs PublicNode. Reordered to lead with the dRPC/PublicNode comparison, then contextualize with the wider board.