While working on some test hardening for
SOLR-12999, I discovered a strange bug related to how SolrExceptions are propogated to HttpClients – sometimes the message set by the server side code when throwing the SolrException is set in the remote exception recieved by the HttpSolrClient, other times it is not.
it's not clear to me if this is specific to the IndexFetcher related code (added in
SOLR-12999) that throw SolrExceptions when the index is in the middle of a full copy, or if it's a general problem that can happen with any SolrException->HTTP->RemoteSolrException via HttpSolrClient that only happens to manifests because of some quirk in the threading of TestReplicationHandlerDiskOverFlow.
(perhaps because we don't have a lot of HTTP level tests checking the exception message?)
At the moment, TestReplicationHandlerDiskOverFlow works around this issue by only comparing the HTTP Staus code to ensure it's what's expected, w/o checking the getMessage() ... I'll attach a patch that demonstrates how including a getMessage() assertion can (sporadically) fail, and includes some nocommit debugging code i added to HttpSolrClient to try and make sense of what's happening...