[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
