[ErykKul]

What this PR does / why we need it:

Since #12712, a full reindex and a recursive collection reindex (also used when moving a collection) queue every dataset at once on the shared async pool, ahead of the indexing of new changes, exports and index time updates. This makes them index one dataset at a time again, as in 6.12.

Which issue(s) this PR closes:

• Closes Batch reindex queues every dataset at once since #12712 #12773

Special notes for your reviewer:

The batch reads the dataset ids from the database, so there is no commit to wait for. MoveDataverseCommand still starts the recursive reindex before its own commit (see the TODO there), as in 6.12.

Suggestions on how to test this:

Run curl http://localhost:8080/api/admin/index and watch the log: datasets are indexed one by one after each "indexing dataset N of M" line. An edit made during the reindex is indexed right away. Unit test: IndexingAfterCommitTest.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

No.

Is there a release notes update needed for this change?:

No, it fixes #12712, which is not released yet.

Additional documentation:

None.

[coveralls]

coverage: 25.55% (+0.02%) from 25.529% — 12773-batch-reindex-one-by-one into develop

[github-actions]

Test Results

407 tests   392 ✅  24m 7s ⏱️
 55 suites   15 💤
 55 files      0 ❌

Results for commit cc18d13.

♻️ This comment has been updated with latest results.

[pdurbin]

Tests are passing. Approved.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:12773-batch-reindex-one-by-one

ghcr.io/gdcc/configbaker:12773-batch-reindex-one-by-one

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.

[landreev]

Interesting/impressive results from a full reindex (the same database snapshot that was used for the 6.12 release candidate test):

31.5 hours total (vs 40.5 hours in 6.12!)

start:

[2026-10-02T19:20:49.764+0000] [Payara 7.2026.9] [INFO] [] [edu.harvard.iq.dataverse.sea
rch.IndexBatchServiceBean] [tid: _ThreadID=265 _ThreadName=__ejb-thread-pool1] [timeMill
is: 1790968849764] [levelValue: 800] [[
  indexing dataverse 1 of 13958 (id=1, persistentId=harvard)]]

end:

[2026-10-04T02:52:27.084+0000] [Payara 7.2026.9] [INFO] [] [edu.harvard.iq.dataverse.search.IndexBatchServiceBean] [tid: _ThreadID=265 _ThreadName=__ejb-thread-pool1] [timeMillis: 1791082347084] [levelValue: 800] [[
  13958 dataverses and 330841 datasets indexed. index all took 113497375 milliseconds. Solr index was not cleared before indexing.
]]

The result checked in in the usual place.

I am not sure I can properly explain where the 9 hours worth of savings (!!) came from myself. So I would appreciate a technical explanation.

But it is fairly clear that it is the datasets with large numbers of files that got much faster to reindex.
Just looking at the last 2 datasets - the monsters with 50K and 64K files respectively:

6.12:

[2026-09-18T14:43:57.318+0000] [Payara 7.2026.8] [INFO] [] [edu.harvard.iq.dataverse.searc
h.IndexBatchServiceBean] [tid: _ThreadID=294 _ThreadName=__ejb-thread-pool1] [timeMillis: 
1789742637318] [levelValue: 800] [[
  indexing dataset 330840 of 330841 (id=10293818)]]

[2026-09-18T14:48:31.374+0000] [Payara 7.2026.8] [INFO] [] [edu.harvard.iq.dataverse.searc
h.IndexBatchServiceBean] [tid: _ThreadID=294 _ThreadName=__ejb-thread-pool1] [timeMillis: 
1789742911374] [levelValue: 800] [[
  indexing dataset 330841 of 330841 (id=8153399)]]

[2026-09-18T14:57:12.094+0000] [Payara 7.2026.8] [INFO] [] [edu.harvard.iq.dataverse.search.IndexBatchServiceBean] [tid: _ThreadID=294 _ThreadName=__ejb-thread-pool1] [timeMillis: 1789743432094] [levelValue: 800] [[
  done iterating through all datasets]]

6.12.1:

[2026-10-04T02:50:16.726+0000] [Payara 7.2026.9] [INFO] [] [edu.harvard.iq.dataverse.search.IndexBatchServiceBean] [tid: _ThreadID=265 _ThreadName=__ejb-thread-pool1] [timeMillis: 1791082216726] [levelValue: 800] [[
  indexing dataset 330840 of 330841 (id=10293818)]]

[2026-10-04T02:50:34.813+0000] [Payara 7.2026.9] [INFO] [] [edu.harvard.iq.dataverse.search.IndexBatchServiceBean] [tid: _ThreadID=265 _ThreadName=__ejb-thread-pool1] [timeMillis: 1791082234813] [levelValue: 800] [[
  indexing dataset 330841 of 330841 (id=8153399)]]

[2026-10-04T02:52:27.079+0000] [Payara 7.2026.9] [INFO] [] [edu.harvard.iq.dataverse.search.IndexBatchServiceBean] [tid: _ThreadID=265 _ThreadName=__ejb-thread-pool1] [timeMillis: 1791082347079] [levelValue: 800] [[
  done iterating through all datasets]]

i.e., 4.5 min. and 8.5 min. vs 15 sec. and 2 min. respectively (!!).

I am satisfied with what I've seen. Merging.