Closed Andrew-Clement closed 7 years ago
I'm encountering this same problem, of a search not responding and having to be Canceled, in a number of other situations.
eg. search on country that appears as a type ahead option (in this case AM) (See also #27)
Suggest that as an interim measure, at least until the underlying issues can be sorted out, provide a timeout feature that would interrupt the search and report "Search timed out. No results found" Setting the timeout period would of course need to allow for the longest legit search.
Below is the console results after submitting a "Containing NSA cities" query, which took 33 secs, but presumably the actual search as opposed to the uploading result was somewhat less than this.
Perhaps the timeout limit could be based on the number of lines in the search query?
Submitting...ixmaps.js:401:3 Query submittedixmaps.js:413:7 Total TRs: 100ixmaps.js:417:9 Total Hops: 1111ixmaps.js:418:9 File Name: e7a6dc67c91009f7100c0e3f84a5a014.jsixmaps.js:419:9 File Size: 427.70 KBixmaps.js:420:9 Execution Time: 33.39 Sec.ixmaps.js:421:9 IXmaps geographic data downloaded! [TRs: 100]ixmaps.gm.js:387:3 Sorting TR Tablesixmaps.gm.js:410:3
And another example of non completion, in this case there should be no results, due to an inadvertent mix-formulation of the search query
Hi Andrew, you are right this is a bug in the search. I believe it's happening when no results are found. Will inspect and report asap.
Good. Thanks Antonio.
The priority of course is to gracefully handle the situation when there are no results to be found.
Then there are the cases where there are results that should be found, but weren't.
This has been fixed. I've corrected a bug that was returning invalid data and causing the search didn't completed.
I've tested the case reported before and now it completes returning no data, as it should. Note that if your have in the rules two originating cities, no TR will match this rule. But the good thing is that now it does not crash.
does : originate : city : Toronto : AND | Traceroutes: 14874 does : terminate : city : Toronto : AND | Traceroutes: 9411 does : goVia : city : Chicago : AND | Traceroutes: 44318 does : originate : city : Chicago : AND | Traceroutes: 1 Total traceroutes : 0
Good to see this Anto!
On 2017-02-08, at 2:12 PM, Antonio Gamba-Bari notifications@github.com wrote:
This has been fixed. I've corrected a bug that was returning invalid data and causing the search didn't completed.
I've tested the case reported before and now it completes returning no data, as it should. Note that if your have in the rules two originating cities, no TR will match this rule. But the good thing is that now it does not crash.
does : originate : city : Toronto : AND | Traceroutes: 14874 does : terminate : city : Toronto : AND | Traceroutes: 9411 does : goVia : city : Chicago : AND | Traceroutes: 44318 does : originate : city : Chicago : AND | Traceroutes: 1 Total traceroutes : 0
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
@Andrew-Clement close?
Good. Working much better now.
Two searches that should be legit, or at least produce an an alert, don't complete and have to be cancelled. In the first case, search on submitter "andrewC" (I missed selecting "AndrewC" from the autocomplete, but even if search needs to be case specific, A message of Not Found would be appropriate. From the console output (below) it appears the parsing doesn't have sufficient error handling.
The second case produces the same results, but may have a different cause. The postal code I mentioned has been used for contributing many routes ( see other recent screen shots in Client issues), but did not appear as possible selection in the autocomplete,. Evidently it isn't being recorded properly.