Improve error message when OverpassQL query mistakenly specifies [out:xml] #1142
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.
Re-opening #1140 under a new branch in the main repo (rather than from my fork).
Fixes maproulette/maproulette3#1908
I've made two logical changes here, which can be separated if necessary.
Checking the
Content-Type
returned by the Overpass API; if it's set to something other thanapplication/json
, mark the challenge as having failed to build, with a specific user-facing error string advising them to use[out:json]
. overpass-api.de returnsContent-Type: application/json
for[out:json]
queries, andapplication/osm3s+xml
for[out:xml]
queries. I believe this change is low risk.Made the query rewriting code more robust, eliminating some of the currently known pitfalls. Previously rewriting would produce syntactically invalid queries (and thus confusing error messages) if
[out:foo]
was present but was not the first directive, or if[timeout:###]
was present but was not the first directive (or was but was followed by[out:foo]
). The previous code was also sensitive to otherwise-insignificant whitespace. The new code isn't perfect, but it is somewhat more robust. It will handle any combination of query settings, provided that they all appear together on the first line of the query.I believe this code will have equivalent behavior to the old code on all queries that are currently working. However, this part of the change is higher risk, because if any queries that work today are mishandled by my new implementation, existing challenges may break when their tasks are rebuilt (and since queries cannot be edited once a challenge is successfully created, this will force users to recreate the challenge, which would be frustrating). So the benefits of this change should be weighed against those risks. If you'd prefer I am happy to remove this change from the PR.
I'm not super familiar with Scala so please also let me know if there are better idioms that I should use or other style problems.
Screenshot of what the new error looks like in the UI: