fix: Prevent microsecond drift when offsets are equal in e2e test

[nahua-aignx]

Addressing this production issue. The cause is from e2e_test.py. When test constants use identical values for due_date_seconds and deadline_seconds (e.g. TEST_APPLICATION_SUBMIT_AND_FIND_* both set to 1 hour, HETA_APPLICATION_SUBMIT_AND_FIND_* both set to 24 hours), the second now() call executes a few hundred microseconds later, producing a due_date that's fractionally after the deadline. SAMIA's SchedulingRequest validator enforces due_date < deadline and correctly rejects this with a 422. The fix captures now = datetime.now(tz=UTC) once and derives both due_date and deadline from that single timestamp, guaranteeing their relative ordering is determined solely by the configured offsets.

[Copilot]

Pull request overview

This PR fixes a flaky E2E test failure caused by capturing datetime.now() twice when due_date_seconds and deadline_seconds are configured to the same offset, which could yield a due_date slightly after deadline and trigger a 422 from SAMIA validation.

Changes:

• Capture a single now = datetime.now(tz=UTC) timestamp in _submit_and_validate.
• Derive both due_date and deadline from the same now to avoid microsecond drift.

[claude]

Claude finished @nahua-aignx's task in 4m 45s —— View job

---

Code Review Complete ✅

I've thoroughly reviewed PR #504. The fix correctly addresses the microsecond drift issue, but there's a critical concern that needs clarification.

---

Summary

Change: Prevents microsecond drift by capturing datetime.now(tz=UTC) once and deriving both due_date and deadline from the same timestamp.

Files Changed: tests/aignostics/platform/e2e_test.py (+4/-2)

---

✅ Strengths

1. ✅ Test Markers Compliant

   • All tests properly marked with @pytest.mark.e2e
   • Tests are correctly categorized for CI execution

2. ✅ Conventional Commit Format

   • Follows standard: fix: Prevent microsecond drift when offsets are equal in e2e test
   • Clear, concise description

3. ✅ Fix Correctness

   • Eliminates race condition where due_date > deadline due to separate datetime.now() calls
   • Guarantees deterministic timestamp calculation
   • Clean implementation that preserves existing structure

4. ✅ No Similar Issues

   • Searched codebase for similar patterns
   • Other datetime.now() usages in this file are single calls (lines 420, 643)

5. ✅ Code Quality

   • SonarQube: 0 new issues, quality gate passed
   • Readable, maintainable code

---

⚠️ Critical Concern: Incomplete Fix?

Issue: When due_date_seconds == deadline_seconds, the fix produces timestamps that still violate SAMIA's validation constraint.

The Problem

Current Test Constants (lines 70-71, 81-82):

TEST_APPLICATION_SUBMIT_AND_FIND_DEADLINE_SECONDS=60*60*1# 1 hourTEST_APPLICATION_SUBMIT_AND_FIND_DUE_DATE_SECONDS=60*60*1# 1 hour ⚠️ EQUALHETA_APPLICATION_SUBMIT_AND_FIND_DUE_DATE_SECONDS=60*60*24# 24 hoursHETA_APPLICATION_SUBMIT_AND_FIND_DEADLINE_SECONDS=60*60*24# 24 hours ⚠️ EQUAL

With This Fix (when offsets are equal):

now=datetime.now(tz=UTC)
due_date=now+timedelta(seconds=3600) # 1 hourdeadline=now+timedelta(seconds=3600) # 1 hour# Result: due_date == deadline ⚠️

SAMIA Validation Constraint (src/aignostics/application/_utils.py:150):

ifparsed_due_date>=parsed_deadline:
raiseValueError("due_date must be before deadline")

Test Validation (tests/aignostics/application/utils_test.py:1180-1184):

deftest_validate_scheduling_constraints_due_date_equal_deadline() ->None:
"""Test that due_date equal to deadline is rejected."""same_time= (datetime.now(tz=UTC) +timedelta(hours=2)).isoformat()
withpytest.raises(ValueError, match=r"due_date must be before deadline"):
validate_scheduling_constraints(same_time, same_time) # ⚠️ FAILS when equal

The Constraint

SAMIA requires strict inequality: due_date < deadline

• ❌ due_date > deadline → Rejected (old code when offsets equal)
• ❌ due_date == deadline → Rejected (new code when offsets equal)
• ✅ due_date < deadline → Accepted (requires different offsets)

Impact

Tests affected (both use equal offset constants):

1. test_platform_test_app_submit_and_wait (line 506) - uses TEST_APPLICATION_SUBMIT_AND_FIND_*
2. test_platform_heta_app_submit (line 604) - uses HETA_APPLICATION_SUBMIT_AND_FIND_*

Both are marked @pytest.mark.scheduled_only, so they only run in scheduled test workflows.

---

🔍 Questions for Author

1. Are the equal offset constants intentional?

   • Should due_date_seconds < deadline_seconds for these tests?
   • Example: DUE_DATE_SECONDS = 60 * 60 * 1 # 1 hour, DEADLINE_SECONDS = 60 * 60 * 2 # 2 hours

2. Is there a follow-up PR to update constants?

   • This fix prevents microsecond drift ✅
   • But equal offsets still fail validation ❌

3. Do production/staging environments use different values?

   • Maybe these constants are overridden in environment config?

---

💡 Recommended Actions

Option 1: Update Constants (Recommended)

Ensure due_date_seconds < deadline_seconds in all test configurations:

# tests/aignostics/platform/e2e_test.pyTEST_APPLICATION_SUBMIT_AND_FIND_DUE_DATE_SECONDS=60*30# 30 minutesTEST_APPLICATION_SUBMIT_AND_FIND_DEADLINE_SECONDS=60*60*1# 1 hourHETA_APPLICATION_SUBMIT_AND_FIND_DUE_DATE_SECONDS=60*60*20# 20 hours HETA_APPLICATION_SUBMIT_AND_FIND_DEADLINE_SECONDS=60*60*24# 24 hours

Option 2: Document Intent

If equal offsets are intentional (e.g., for testing validation errors), add a comment explaining why.

---

📋 Testing Checklist

• Test markers present (@pytest.mark.e2e)
• Commit message follows conventional commits
• Fix addresses microsecond drift
• No similar issues in codebase
• Code quality passes (SonarQube, linting)
• ⚠️ Validation constraint satisfaction (needs clarification)

---

Verdict

Conditional Approval ✅⚠️

The fix is technically correct for eliminating microsecond drift and should be merged. However, please clarify the equal offset constants to ensure the affected tests won't continue failing with 422 validation errors.

If the constants are meant to be equal, this PR is incomplete. If they should be different, a follow-up PR or amendment is needed.

---

Note: I've reviewed this PR according to the comprehensive testing standards and medical device software guidelines for this repository. This is medical device software requiring the highest engineering standards.

---

| Branch: fix/PAPI-4701-testerr-scheduling-payload

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.
see 4 files with indirect coverage changes

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud