[
https://issues.apache.org/jira/browse/SOLR-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048306#comment-16048306
]
ASF subversion and git services commented on SOLR-10833:
--------------------------------------------------------
Commit 5e438bbe2783f8fc16da41d660fde7c7d65d7e3e in lucene-solr's branch
refs/heads/branch_6x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e438bb ]
SOLR-10833: Updated CHANGES to include SOLR-10833
> Numeric FooPointField classes inconsistent with TrieFooFields on malformed
> input: throw NumberFormatException
> -------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch,
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are
> just allowing the NumberFormatExceptions to be thrown as is, which means they
> propagate up and are eventually treated as a SERVER_ERROR when responding to
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks
> how these errors are handled in SolrCloud when the requests have been
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the
> TrieFooField classes on bad input (both when adding a document, or query
> creating a field query)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
