Bug 40962: Fix race condition in OAI Server test for OpacHiddenItems

The 'Tests for OpacHiddenItems' subtest captured Perl's wall clock time
*after* calling build_sample_item(), then used that timestamp as both the
expected OAI datestamp and the 'from' filter. On slow systems the INSERT
can straddle a second boundary, so MySQL records T:40 while dt_from_string
returns T:41, causing noRecordsMatch on the ListRecords tests and a
datestamp mismatch on the GetRecord tests.

Fix by calling $item->discard_changes and deriving $utc_timestamp from the
timestamp MySQL actually assigned, matching the pattern already used in the
Bug 19725 subtest in the same file.

Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This commit is contained in:
Martin Renvoize 2026-03-23 00:21:39 +01:00
parent ad1caed65c
commit cde9628b86
No known key found for this signature in database
GPG Key ID: 2D86E0EAEC83711B
1 changed files with 9 additions and 4 deletions

View File

@ -589,10 +589,15 @@ subtest 'Tests for OpacHiddenItems' => sub {
t::lib::Mocks::mock_preference(
'OAI-PMH:ConfFile' => File::Spec->rel2abs( dirname(__FILE__) ) . '/oaiconf_items.yaml' );
$schema->storage->txn_begin;
my $builder = t::lib::TestBuilder->new;
my $item = $builder->build_sample_item();
my $biblio = $item->biblio;
my $utc_datetime = dt_from_string( undef, undef, 'UTC' );
my $builder = t::lib::TestBuilder->new;
my $item = $builder->build_sample_item();
my $biblio = $item->biblio;
# Read the timestamp MySQL actually assigned rather than capturing Perl's
# wall clock after the fact — on slow systems the two can differ by 1 second,
# causing the 'from' filter to miss the just-created record.
$item->discard_changes;
my $utc_datetime = dt_from_string( $item->timestamp );
my $utc_timestamp = $utc_datetime->ymd . 'T' . $utc_datetime->hms . 'Z';
my $get_items = {