lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Assigned] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
Date Thu, 31 Jan 2019 18:45:00 GMT


Hoss Man reassigned SOLR-13210:

      Assignee: Hoss Man
    Attachment: SOLR-13210_demonstrate_broken_test.patch

I've attached a SOLR-13210_demonstrate_broken_test.patch that demonstrates how the test logic
is so falwed that even if we mock out the queries to return the exact same hardcoded docs
from every shard, it still passes. 

The logic as written is so weird, i'm not actually sure what the original intent of idMap
is – whether it was ment to contain the first 2 sections (app+user) of a TriLevel id, or
just the first (app) section -- because based on my understanding of the contract for compositeIds,
neither one is guaranteed to only exist in a single shard in the situation where a {{/numBits}}
is specified -- as it is in this test.

[~shalinmangar] -- some guidance here would be appreciated

> TriLevelCompositeIdRoutingTest makes no sense -- can never fail
> ---------------------------------------------------------------
>                 Key: SOLR-13210
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>            Priority: Major
>         Attachments: SOLR-13210_demonstrate_broken_test.patch
> i recently fixed tweaked TriLevelCompositeIdRoutingTest to lower the node/shard count
on TEST_NIGHTLY because it was constantly causing an OOM.
> While skimming this test i realized that (other then the OOM, or other catastrophic failure
in solr) it was garunteed to never fail, rgardless of what bugs might exist in solr when routing
an update/query:
> * it doesn't sanity check that any docs are returned from any query -- so if commit does
nothing and it gets no results from each of the shard queries, it will still pass
> * the {{getKey()}} method -- which throws away anything after the last "!" in a String
-- is called redundently on it's own output to populate an {{idMap}} ... but not before the
first result is used do to acontainsKey assertion on that same {{idMap}}
> ** ie: if {{app42/7!user33!doc1234}} is a uniqueKey value, then {{app42/7!user33}} is
what the assert !containsKey checks the Map for, but  {{app42/7}} is what gets put in the

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message