Repository navigation
Conversation
… availability reads at the restaurant page
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.
Summary
Two message changes on the OpenTable tools, from a bench of
opentable-available-timesin plain browsers:search_restaurants: a first-pageno_resultsnow 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 orget_restaurantwith the short address.get_availabilityandprepare_reservation(sharedlib/opentable-availability.js): achallengenow 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 inno_resultsand the profile URL in a refused availability read; both messages stay within the 300-charactererror_messagebound.node scripts/validate-registry.mjs: valid.no_resultswent straight toget_restaurant. On main, all four trials that hit it reworded the search and tried again. Thechallengepath did not occur live in these runs. It is fixture-tested only.All five changed tools were already
draft, so the registry is unchanged.