Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
9.0, 9.1, 9.1.1
-
None
-
None
Description
I think there was a regression introduced in SOLR-15790 where the rid param is no longer logged correctly.
Solr 8 logs, rid=-1 logged with final query after distributed results were collected:
.... INFO (qtp1482246673-23) [c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica_n1] o.a.s.c.S.Request [gettingstarted_shard1_replica_n1] webapp=/solr path=/select params={q=*:*&indent=true&q.op=OR&_=1675975274863} rid=-1 hits=0 status=0 QTime=3
Solr 9 logs:
.... INFO (qtp351877391-20) [c:gettingstarted s:shard2 r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request webapp=/solr path=/select params={q=*:*&indent=true&q.op=OR&useParams=&_=1675975376183} hits=0 status=0 QTime=6
I narrowed down the issue to a problem with the SearchHandler. the part that determines if the rid param should be added does not match with the lifecycle of the ResponseBuilder.
basically the decision to add the param is done in tagRequestWithRequestId [0] based on the rb.isDistrib flag which will only be computed later in getAndPrepShardHandler [1], so at the moment where this is supposed to be added, it's always false. this param will never be logged.
Even though it's just logging, I see this as a potential regression. I think having this info logged is very valuable.
Attachments
Issue Links
- is caused by
-
SOLR-15790 Populate MDC with rid (CommonParams.REQUEST_ID)
- Closed
- links to