[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-dev
Subject:    [jira] [Assigned] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
From:       "Hoss Man (JIRA)" <jira () apache ! org>
Date:       2019-01-31 18:45:00
Message-ID: JIRA.13213149.1548959823000.214708.1548960300643 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

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: https://issues.apache.org/jira/browse/SOLR-13210
> 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 Map



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]