Scope testScanSearch to its own scans instead of a global count

[dmaffitt]

Problem

testScanSearch fails on a shared / long-lived server (observed against a live instance) at:

final int expectedScanCount = getScanCountFromDataApi();
assertTrue(Objects.equals(expectedScanCount, results.size())
        || Objects.equals(scanIds.size(), results.size()));

It compares the xnat:mrScanData advanced-search result size against the /experiments session listing count — but the two enforce read permission at different levels:

• /experiments?columns=xnat:mrSessionData/scans/scan/ID surfaces a scan whenever the session is readable.
• The xnat:mrScanData stored search requires read on the scan element itself.

On a long-lived server, leftover projects from custom-permission test classes leave main in groups that grant xnat:mrSessionData read but not xnat:mrScanData read. Those scans appear in the session listing but are (correctly) excluded from the scan search. Non-MR scans (e.g. xnat:petScanData) inside MR sessions add to the gap. So the two global counts are incommensurable, and neither equals scanIds.size() once unrelated data is present.

Investigation on a live server: search returned 44 scans, listing 53; the 9-scan gap was 2 petScanData + 7 mrScanData in 7 residual custom-permission projects (session-read, not scan-read). Not a product bug and not a regression — the endpoints legitimately differ; the assertion just isn't isolated.

Fix

Restrict the result set to the scans this test created and assert the search returns exactly them:

final List<String> ownScansInResults = getValuesByField(results, ID).stream()
        .filter(scanIdsSet::contains)
        .collect(Collectors.toList());
assertEquals("scan search should return exactly this test's own scans", scanIds, ownScansInResults);

This still verifies the search finds this test's scans (and returns each exactly once) while being robust to any unrelated pre-existing data. Verified: testScanSearch now passes against the live long-lived server where the old assertion failed.

Note on overlap

This removes the only caller of getScanCountFromDataApi(). The helper is intentionally left in place here because a separate PR (fix/advanced-search-distinct-count) reworks the data-API count helpers; whichever of the two lands second needs only a trivial rebase. No functional overlap between the two diffs.

🤖 Generated with Claude Code