[ 
https://issues.apache.org/jira/browse/SOLR-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759663#comment-17759663
 ] 

Chris M. Hostetter commented on SOLR-16825:
-------------------------------------------

For the past 4 days, every testclass that inherits 
{{AbstractIncrementalBackupTest.testBackupIncremental}} has been failing 
reliably during nightly jenkins runs on main.

The seeds reproduce for me locally...

{noformat}
   >     java.lang.AssertionError: expected:<1> but was:<null>
   >         at 
__randomizedtesting.SeedInfo.seed([FC42CD1F24172A4C:FB8762D418FF1431]:0)
   >         at org.junit.Assert.fail(Assert.java:89)
   >         at org.junit.Assert.failNotEquals(Assert.java:835)
   >         at org.junit.Assert.assertEquals(Assert.java:120)
   >         at org.junit.Assert.assertEquals(Assert.java:146)
   >         at 
org.apache.solr.cloud.api.collections.AbstractIncrementalBackupTest.testBackupIncremental(AbstractIncrementalBackupTest.java:295)

...

  2> NOTE: reproduce with: gradlew test --tests 
LocalFSCloudIncrementalBackupTest.testBackupIncremental 
-Dtests.seed=FC42CD1F24172A4C -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Solr/Solr-NightlyTests-main/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-TN -Dtests.timezone=Kwajalein -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
{noformat}

Git bisect identifies 3 possible first bad commits...

* SOLR-16825: First known commit where code compiles clean, and test fails.
** 0a47cf8ac8420feb623600ff736aed6503b53b20
* SOLR-16933: Neither commit compiles, so bisect must skip and can't confirm if 
test passes or fails...
** f5b0d22f06363a06db25368f70e0d429a0e3b192
** 57acde3752bec704442cd08d54fc516f93ee4169

...both issues touch backup related code, so I'm posting this commit in both 
issues as i don't have a good grasp of which one seems like the more likelye 
suspect.

Full bisect log...

{noformat}
# bad: [ce6c13e41806233daaf25f1a7545c7aad34c169d] SOLR-15367 Convert "rid" 
functionality into a default Tracer (#1854)
# good: [473cea28b55dcf03fb2338399af321f425c90002] Cleaning up old code to 
prevent warnings (#1834)
git bisect start 'ce6c13e41806233daaf25f1a7545c7aad34c169d' 
'473cea28b55dcf03fb2338399af321f425c90002'
# skip: [57acde3752bec704442cd08d54fc516f93ee4169] SOLR-16933: Use 
JSONMapResponseWriter for CLI errors
git bisect skip 57acde3752bec704442cd08d54fc516f93ee4169
# bad: [0a47cf8ac8420feb623600ff736aed6503b53b20] SOLR-16825: Migrate v2 
definitions to 'api' module (#1859)
git bisect bad 0a47cf8ac8420feb623600ff736aed6503b53b20
# skip: [f5b0d22f06363a06db25368f70e0d429a0e3b192] SOLR-16933: Include full 
query response in API tool (#1863)
git bisect skip f5b0d22f06363a06db25368f70e0d429a0e3b192
# only skipped commits left to test
# possible first bad commit: [0a47cf8ac8420feb623600ff736aed6503b53b20] 
SOLR-16825: Migrate v2 definitions to 'api' module (#1859)
# possible first bad commit: [57acde3752bec704442cd08d54fc516f93ee4169] 
SOLR-16933: Use JSONMapResponseWriter for CLI errors
# possible first bad commit: [f5b0d22f06363a06db25368f70e0d429a0e3b192] 
SOLR-16933: Include full query response in API tool (#1863)
{noformat}






> Generate Java bindings from OpenAPI spec
> ----------------------------------------
>
>                 Key: SOLR-16825
>                 URL: https://issues.apache.org/jira/browse/SOLR-16825
>             Project: Solr
>          Issue Type: Improvement
>          Components: v2 API
>            Reporter: Jason Gerlowski
>            Priority: Major
>          Time Spent: 6h 40m
>  Remaining Estimate: 0h
>
> SOLR-16346 added support to Solr's build to generate an "OpenAPI spec" file 
> describing our v2 API.  But currently, this spec file isn't actually used by 
> Solr in any way.
> Spec files can be used for a variety of purposes, including to [generate 
> client bindings|https://github.com/OpenAPITools/openapi-generator] for using 
> the API.
> The client generation capabilities provided by the OpenAPI project cover a 
> variety of languages, but it make sense for Solr to start with Java since we 
> already have a Java client that requires continual effort to keep up to date. 
>  It'd be a big win for the project if we were able to replace some or all of 
> the manually maintained "SolrRequest" implementations in SolrJ with 
> automatically generated code.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to