Open ghost opened 9 years ago
whats strange is i didn't see a bugsnag hit for this.
Reproduced in Firefox on OSX with the location listed in the screenshot (Maxfield's House of Caffeine). However, I was not able to reproduce this issue using different landmarks with apostrophes (Lalime's, Fred's Deli, Peet's Coffee). I also saw the bug while searching for its street address "398 Dolores Street, San Francisco, CA, United States" and also with just the street name ("Dolores Street, San Francisco, CA, United States"). Also had this same error when searching "3321 16th St, San Francisco, CA, United States." So probably not a string quoting bug.
FWIW I reproduced on live for Maxfield's House of Caffeine but could not do so locally.
Live:
Local:
Trying to figure out what's different here:
#<Restroom id: 7, name: "Maxfield's House of Caffine", street: "398 Dolores St", city: "san francisco", state: "ca", accessible: true, unisex: true, directions: "in back to the left", comment: "no key", latitude: 37.7630316, longitude: -122.4263985, created_at: "2014-02-02 20:49:02", updated_at: "2014-02-02 20:49:02", downvote: 0, upvote: 0, country: "US", changing_table: false>
#<Restroom id: 6, name: "Maxfield's House of Caffine", street: "398 Dolores St", city: "san francisco", state: "ca", accessible: true, unisex: false, directions: "in back to the left", comment: "no key", latitude: 37.7631676, longitude: -122.4266179, created_at: "2017-03-26 20:26:39", updated_at: "2017-03-26 20:26:39", downvote: 0, upvote: 0, country: "US", changing_table: false>
First one is prod, second is seed DB. Don't see anything that would cause this error in there :/ I can reproduce in prod thoough
Not sure if it's relevent to the error, but the entries are both missing the 'e' in 'caffeine'.
Maybe prod fails when trying to bring up the entry, due to the typo?
I can reproduce on production by typing "Maxfield's" and hitting enter, "Maxfield's House of Caffeine" and hitting enter, or "Maxfield's" and clicking on the location from the dropdown.
Other businesses with "Maxfield's" in the name work fine, such as "Maxfield's Pancake House" (multiple franchise locations throughout the US).
Also FWIW, when I get the error by typing "Maxfield's", or "Maxfield's House" etc. without clicking on the full address, I get this lat and long in the url: http://www.refugerestrooms.org/restrooms?utf8=%E2%9C%93&lat=43.4549719&long=-85.0437973&search=Maxfield%27s
43.45 North, -85.04 West, which is apparently dead-centered on the town of Wyman, Michigan.
This location appears to be Maxfield's Restaurant, North Wyman Road, Blanchard, MI, United States
Does anyone know the commit id, from when the live site went up? I (or anyone) can test it locally using that commit and see what errors there are on the command line of the vagrant box.
@DeeDeeG That I don't have any clue for. The original versions of the site were not tracked with releases, that has been a more recent thing for us. At the time we went live, it was just me pushing code. ^.^
Any longitude from -122.422
to -122.428
causes this.
I suggest we fudge the longitude to be outside that range.
Also I am very confused by this, but y'know, we have a solution.
Edit: hmm, on second thought, the error happens on our server. And when running the live site, we are getting the lat/long from Google. So either Google has to get an updated location, or our server stack has to get fixed.
Edit 2: I think the reason changing the latitude fixes this... is that entering a different enough latitude ends up being far enough away that Maxfield's is not on the first page of results. However, going through the pages of nearby restrooms, the 3rd or 4th page does not load. I think that's the page that Maxfield's would be on. Conclusion: trying to render the entry for Maxfield's is where the problem lies.
I suspect it's a string quoting bug and if so it might make refuge more vulnerable to mischief. reproduced on chrome and safari in os x.