[
https://issues.apache.org/jira/browse/SOLR-12029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated SOLR-12029:
----------------------------
Description:
While writing a unit test I became curious about exactly what statuses can come
back (mostly checking that negative values can never be returned) and when I
looked at the ErrorCode enum I realized that the "UNKNOWN" code has the the
value 0, which is the same status value that is used to indicate success. Since
the code in org.apache.solr.core.SolrCore#postDecorateResponse sets the error
code as the status in the event of an error, any client that looks at the
status value to determine if the request succeeded would conclude that an
UNKNOWN error was a success.
This value is explicitly set into SolrExceptions twice in RestoreCore once in
DeleteReplicaCmd and once in PageTool.
Also org.apache.solr.search.join.GraphQueryTest#doGraphQuery uses it as a
default representing success.
I'm not entirely sure of the history or whether those exception cases really do
want to be interpreted as success, so I'm putting this issue up here to get
some discussion of whether these are bugs, and if perhaps we should refactor
ErrorCode.UNKNOWN to ErrorCode.SUCCESSFUL_REQUEST to avoid future confusion?
Possibly we need to then add in a new ErrorCode.UNKNOWN that has some other
value.
was:
While writing a unit test I became curious about exactly what statuses can come
back (mostly checking that negative values can never be returned, and when I
looked at the ErrorCode enum I realized that the "UNKNOWN" code has the the
value 0, which is the same status value that is used to indicate success. Since
the code in org.apache.solr.core.SolrCore#postDecorateResponse sets the error
code as the status in the event of an error, any client that looks at the
status value to determine if the request succeeded would conclude that an
UNKNOWN error was a success.
This value is explicitly set into SolrExceptions twice in RestoreCore once in
DeleteReplicaCmd and once in PageTool.
Also org.apache.solr.search.join.GraphQueryTest#doGraphQuery uses it as a
default representing success.
I'm not entirely sure of the history or whether those exception cases really do
want to be interpreted as success, so I'm putting this issue up here to get
some discussion of whether these are bugs, and if perhaps we should refactor
ErrorCode.UNKNOWN to ErrorCode.SUCCESSFUL_REQUEST to avoid future confusion?
Possibly we need to then add in a new ErrorCode.UNKNOWN that has some other
value.
> ErrorCode.UNKNOWN suspicious usages
> -----------------------------------
>
> Key: SOLR-12029
> URL: https://issues.apache.org/jira/browse/SOLR-12029
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: master (8.0)
> Reporter: Gus Heck
> Priority: Major
>
> While writing a unit test I became curious about exactly what statuses can
> come back (mostly checking that negative values can never be returned) and
> when I looked at the ErrorCode enum I realized that the "UNKNOWN" code has
> the the value 0, which is the same status value that is used to indicate
> success. Since the code in org.apache.solr.core.SolrCore#postDecorateResponse
> sets the error code as the status in the event of an error, any client that
> looks at the status value to determine if the request succeeded would
> conclude that an UNKNOWN error was a success.
> This value is explicitly set into SolrExceptions twice in RestoreCore once in
> DeleteReplicaCmd and once in PageTool.
> Also org.apache.solr.search.join.GraphQueryTest#doGraphQuery uses it as a
> default representing success.
> I'm not entirely sure of the history or whether those exception cases really
> do want to be interpreted as success, so I'm putting this issue up here to
> get some discussion of whether these are bugs, and if perhaps we should
> refactor ErrorCode.UNKNOWN to ErrorCode.SUCCESSFUL_REQUEST to avoid future
> confusion? Possibly we need to then add in a new ErrorCode.UNKNOWN that has
> some other value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
