Skip to content

opentable.com: name the searched area on no_results and point refused availability reads at the restaurant page - #144

Draft
yummybomb wants to merge 1 commit into
mainfrom
hypeship/opentable-search-and-challenge-guidance
Draft

yummybomb wants to merge 1 commit into
mainfrom
hypeship/opentable-search-and-challenge-guidance

Conversation

@yummybomb

@yummybomb yummybomb commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Two message changes on the OpenTable tools, from a bench of opentable-available-times in plain browsers:

  • search_restaurants: a first-page no_results now names the area OpenTable searched and says what to do. OpenTable reads a place in the text only when its query parser recognizes it, and otherwise searches near the browser's location. In 4 of 5 treatment trials on main, "Kokkari Estiatorio San Francisco" came back empty. The old message did not record which area was searched; in live probes of that query, 2 fresh browsers searched the Washington, D.C. area and got 0 results, 5 recognized San Francisco, and 2 more came back empty without the area being recorded. The message now reads "...no restaurants matching this search in Washington, D.C. Area. It searches near the browser's location when it does not recognize the place in the query; ..." and points at a shorter query or get_restaurant with the short address.
  • get_availability and prepare_reservation (shared lib/opentable-availability.js): a challenge now includes the restaurant's profile URL for the requested date, time and party, and says to read its booking widget without selecting a time. Before, the message was only "OpenTable refused or challenged the request". The site can refuse these reads while that page still shows times.

No change to requests, parsing or output shape.

Testing

  • node --test "tests/*.test.mjs": 4485 pass. New assertions cover the searched area in no_results and the profile URL in a refused availability read; both messages stay within the 300-character error_message bound.
  • node scripts/validate-registry.mjs: valid.
  • Bench, 2026-10-28, Haiku 5.5 low, plain browsers, 5 pairs: 5 of 5 in both arms on main and on this branch. With this branch, the one trial that hit no_results went straight to get_restaurant. On main, all four trials that hit it reworded the search and tried again. The challenge path did not occur live in these runs. It is fixture-tested only.

All five changed tools were already draft, so the registry is unchanged.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant