Bug 25824 - DecreaseLoanHighHolds.t is still failing randomly 2
Summary: DecreaseLoanHighHolds.t is still failing randomly 2
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Test Suite (show other bugs)
Version: 22.11
Hardware: All All
: P5 - low normal (vote)
Assignee: Chris Cormack
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 25551
  Show dependency treegraph
 
Reported: 2020-06-19 17:05 UTC by Victor Grousset/tuxayo
Modified: 2023-12-10 09:22 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Grousset/tuxayo 2020-06-19 17:05:02 UTC
After 188 local run I could reproduce on 19.05.x the failure that happening on this build:
https://jenkins.koha-community.org/view/19.05/job/Koha_19.05_D9/229/consoleText
 
t/db_dependent/DecreaseLoanHighHolds.t .. 2/17 
#   Failed test 'Static mode should exceed threshold'
#   at t/db_dependent/DecreaseLoanHighHolds.t line 131.
#          got: '0'
#     expected: '1'

#   Failed test 'Should have duration of 1'
#   at t/db_dependent/DecreaseLoanHighHolds.t line 133.
#          got: '0'
#     expected: '1'

#   Failed test 'due_date should be a DateTime object'
#   at t/db_dependent/DecreaseLoanHighHolds.t line 134.
#          got: ''
#     expected: 'DateTime'
Can't call method "hour" on an undefined value at t/db_dependent/DecreaseLoanHighHolds.t line 137.
# Looks like your test exited with 11 just after 5.
t/db_dependent/DecreaseLoanHighHolds.t .. Dubious, test returned 11 (wstat 2816, 0xb00)

It was like 30 min, so not so hard to reproduce (assuming it wasn't huge luck)

Happens also in Ubuntu 18.04 for 19.05.x branch. (if that can help)
https://jenkins.koha-community.org/job/Koha_19.05_U18/236/consoleText

It's the second time a few days. It's good that it's not a rare issue.
Comment 1 Victor Grousset/tuxayo 2020-06-19 17:05:46 UTC
Also failing in the past in 17.05.
See bug 19705 comment 6
and bug 19705 comment 7
Comment 2 Paul Navarrete 2023-09-21 20:35:13 UTC
I'm having trouble with the decreaseLoanHighHolds system preference and came across this bug. I have the preference set to reduce the loan period for items with more than 1 hold "over the number of holdable items on the record". Essentially I just want the loan period to decrease when one item has multiple holds on it, but the loan period does not decrease properly at checkout.
We used to have the value set to "on the record" rather than "over the number of holdable items on the record". This would trigger the
decreased loan period correctly, but it would also do that in
situations we didn't want, such as one patron having holds on two
items on the same bib record. It would just see two holds on one bib
record and automatically decrease the loan.
So I'd really like for this configuration to work properly as "over the number of holdable items on the record".
Comment 3 Katrin Fischer 2023-09-21 21:32:49 UTC
(In reply to Paul Navarrete from comment #2)
> I'm having trouble with the decreaseLoanHighHolds system preference and came
> across this bug. I have the preference set to reduce the loan period for
> items with more than 1 hold "over the number of holdable items on the
> record". Essentially I just want the loan period to decrease when one item
> has multiple holds on it, but the loan period does not decrease properly at
> checkout.
> We used to have the value set to "on the record" rather than "over the
> number of holdable items on the record". This would trigger the
> decreased loan period correctly, but it would also do that in
> situations we didn't want, such as one patron having holds on two
> items on the same bib record. It would just see two holds on one bib
> record and automatically decrease the loan.
> So I'd really like for this configuration to work properly as "over the
> number of holdable items on the record".

Hi Paul, this is an old bug about the automatic tests. Please file your problem as a new bug. But I think you might be misunderstanding the setting. It's about items on the record - if there are multiple items, the decrease will happen later.