VSB-TUO/Fix EmbargoImportIT time-bomb: compute embargo dates dynamically

[Kasinhou]

Summary

Fixes the two consistently failing integration tests on customer/vsb-tuo:

• EmbargoImportIT.testStandardEmbargoImport (line 174) — AssertionError: Embargo policy should have start date
• EmbargoImportIT.testMultipleBitstreamsEmbargo (line 362) — AssertionError: Each embargo policy should have start date

Verdict: the test was wrong, not the embargo logic. The test hardcoded a "future" embargo end date (2026-06-30) that rolled into the past — a time-bomb test.

Root cause analysis

EmbargoImportIT declared:

private static final String EMBARGOEND_DATE_FUTURE = "2026-06-30";
private static final String EXPECTED_POLICY_START_DATE = "2026-07-01";

ItemImportServiceImpl.processEmbargoMetadata() intentionally refuses to apply an embargo whose end date has already passed (if (endDate.before(new Date())) { ... return; }), so once real time passed 2026-06-30 the import stopped creating the embargo ResourcePolicy, its start date was null, and both assertNotNull checks failed.

Hypotheses considered and ruled out

• (a) Regression in the embargo/resource-policy logic — ruled out. The branch head (60f0a21a) has been unchanged since 2026-06-08. Scheduled CI on that same commit was green through 2026-06-29 20:40 UTC and has failed on every run since 2026-06-30 00:57 UTC — the exact moment DCDate("2026-06-30") (midnight UTC, 2026-06-30) became a past date. No code changed; only the calendar moved.
• (c) vsb-tuo customization diverging from upstream — ruled out. Both the embargo import logic and this test are the vsb-tuo/dataquest customization itself (PRs VSB-TUO/EDISON SAF import with embargo #1058, VSB-TUO/feat: SAF Import/Update – embargo improvements & item page display #1287); there is no upstream org.dspace.app.itemimport.EmbargoImportIT to diverge from. The hardcoded date has been in the test since it was written (2025-09), when it was still ~9 months in the future.
• (b) Test encodes an incorrect assumption — confirmed. Skipping embargoes with past end dates is correct, documented behavior of the importer, and this very suite asserts it in testPastEmbargoDateNoPolicy ("Should not have embargo policy for past dates"). The incorrect assumption is that a fixed calendar date stays in the future.

Fix

Compute the embargo dates relative to the test run instead of hardcoding them:

private static final LocalDate EMBARGO_END_FUTURE = LocalDate.now().plusYears(1);
private static final String EMBARGOEND_DATE_FUTURE = EMBARGO_END_FUTURE.toString();
private static final String EXPECTED_POLICY_START_DATE = EMBARGO_END_FUTURE.plusDays(1).toString();

No assertion was relaxed or removed: the test still requires the embargo policy to exist for the Anonymous group, to have a non-null start date, and that the start date equals embargo end + 1 day in yyyy-MM-dd format (LocalDate.toString() is the same ISO format previously hardcoded). EMBARGOEND_DATE_PAST stays hardcoded (2020-01-01) since a past date can never expire.

Test evidence

	Before	After
EmbargoImportIT (local, Windows)	Tests run: 5, Failures: 2 (lines 174 / 362, exact CI errors)	Tests run: 5, Failures: 0
Full dspace-api IT suite	CI: Tests run: 458, Failures: 2 (both EmbargoImportIT, failed even with rerunFailingTestsCount=2 → consistent, not flaky)	Local: Tests run: 458, EmbargoImportIT green; remaining failures only in ItemImportCLIIT (see below)

Note on ItemImportCLIIT (local only, pre-existing): on my Windows machine ItemImportCLIIT fails nondeterministically (9 failures in the full run, 1 when run in isolation) with java.nio.file.FileSystemException: ... The process cannot access the file because it is being used by another process during temp-file cleanup — a Windows file-locking issue. It is unrelated to this change (this PR touches only constants in EmbargoImportIT) and the class passes on Linux CI, where the pre-fix run's only failures across all 458 tests were the two embargo tests. CI on this PR should come back fully green.

cc @Kasinhou

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 76e7e31f-700f-44d3-a2fb-4612ccd6c811

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}