https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach@kit.edu, | |michaela.sieber@kit.edu -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au, | |m.de.rooy@rijksmuseum.nl, | |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #2 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 161067 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161067&action=edit Bug 35819: Retry to fetch job if does not enqueued yet If a job has been enqueued in the middle of a txn, the worker will fetch the job but fail because it's not in the DB yet. The uglier but most effective (as a quick fix and easily backportable fix) is to... wait a bit. This patch suggests to sleep 1sec and retry, 10 times. It should be enough for the majority of the jobs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 161071 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161071&action=edit Bug 35819: Notify NACK when Job ID not found -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #4 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I'm not 100% confident with my patch, but sending in case it might open for another options to solve the issue. The idea is to not ACK if the job is not found, making rabbit resend the notification to subscribers. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #6 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Cannot teat right now but not sure nack will re-enqueue btw -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #8 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- The idea of the 2nd patch does attract me more than the sleep/retry. This should serve imo as a temporary bugfix/workaround for backports etc and like we discuss on 35092 that we should move to a less hybrid approach. We should read new jobs from either MQ or DB, not both. See the options in bug 35092 comment7. Current stand shows more people choose option2. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #9 from Nick Clemens <nick@bywatersolutions.com> --- Why not move the enqueue out of the transaction? We can pass "skip_holds_queue" to the store and then handle as we do indexing -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #11 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Nick Clemens from comment #9)

Why not move the enqueue out of the transaction? We can pass "skip_holds_queue" to the store and then handle as we do indexing

The thing is, you cannot always know something is going to trigger a background job. So coding will become nightmare-ish. -- You are receiving this mail because: You are watching all bug changes.

SELECT * FROM background_jobs; => FAIL: Notice the job ID mentioned on 2 stands as 'new'.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161067|0 |1 is obsolete| | Attachment #161071|0 |1 is obsolete| | --- Comment #12 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 161139 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161139&action=edit Bug 35819: Notify NACK and requeue when Job ID not found This patch makes the worker reject the incoming frame for putting the message back in the queue, in the event the job id doesn't exist yet. Which is the case when some actions are being triggered inside a transaction which hasn't been commited to the DB yet. To test you will need 3 KTD shells (a) mysql: $ ktd --shell k$ sudo koha-mysql kohadev (b) logs: $ ktd --shell # for restarting the worker and looking at the logs k$ sudo koha-worker --restart kohadev ; tail -f /var/log/koha/kohadev/worker-*.log (c) running the test: $ ktd --shell 1. Have (a), (b) and (c) terminals ready 2. On (c), run: $ perl -MKoha::Database -MKoha::BackgroundJob::BatchUpdateBiblioHoldsQueue -e 'Koha::Database->schema->txn_do( sub { Koha::BackgroundJob::BatchUpdateBiblioHoldsQueue->new->enqueue({ biblio_ids => [ 1 ] }); sleep 1; } );' => FAIL: * (b) shows (once) an error about a job not existing 3. On (a) run: 4. Apply this patch 5. Ctrl+c on (b), and re-run to launch the worker with the patch applied 6. Repeat 2 => SUCCESS (partial): The error about the job not existing is displayed many times 7. Repeat 3 => SUCCESS: The job ID mentioned on 6 stands as 'finished'. 8. Sign off :-D Discussion: * The `requeue` header I added is correct, but it is the default behavior anyway. I prefered to make it explicit, though. * To avoid that bunch of retries, we should requeue with some delay. I didn't manage to make it work (yet) but there's a 'delay' plugin for rabbit [1]. We already install the 'stomp' plugin in koha-common.postinst. But this plugin requires downloading it. Which would require further investigation. * As Nick and Marcel pointed, we need to revisit the whole architecture, the need of a MQ (DB polling wouldn't have this problem), etc. But that's for another place. [1] https://hevodata.com/learn/rabbitmq-delayed-message/#:~:text=To%20delay%20a%.... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jonathan.druart+koha@gmail. |tomascohen@gmail.com |com | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #15 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #14)

Hmm Seeing: PRECONDITION_FAILED - unknown delivery tag 1

"PRECONDITION_FAILED - unknown delivery tag" usually happens because of double ack-ing, ack-ing on wrong channels or ack-ing messages that should not be ack-ed. => ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #17 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- https://www.cloudamqp.com/docs/delayed-messages.html Is this a usable pattern? Move it to a 'delayed' queue? Where rabbitmq pushes it back to the work queue when it 'times out'. -- You are receiving this mail because: You are watching all bug changes.

SELECT * FROM background_jobs; => FAIL: Notice the job ID mentioned on 2 stands as 'new'.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161139|0 |1 is obsolete| | --- Comment #18 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 161172 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161172&action=edit Bug 35819: Notify NACK and requeue when Job ID not found This patch makes the worker reject the incoming frame for putting the message back in the queue, in the event the job id doesn't exist yet. Which is the case when some actions are being triggered inside a transaction which hasn't been commited to the DB yet. To test you will need 3 KTD shells (a) mysql: $ ktd --shell k$ sudo koha-mysql kohadev (b) logs: $ ktd --shell # for restarting the worker and looking at the logs k$ sudo koha-worker --restart kohadev ; tail -f /var/log/koha/kohadev/worker-*.log (c) running the test: $ ktd --shell 1. Have (a), (b) and (c) terminals ready 2. On (c), run: $ perl -MKoha::Database -MKoha::BackgroundJob::BatchUpdateBiblioHoldsQueue -e 'Koha::Database->schema->txn_do( sub { Koha::BackgroundJob::BatchUpdateBiblioHoldsQueue->new->enqueue({ biblio_ids => [ 1 ] }); sleep 1; } );' => FAIL: * (b) shows (once) an error about a job not existing 3. On (a) run: 4. Apply this patch 5. Ctrl+c on (b), and re-run to launch the worker with the patch applied 6. Repeat 2 => SUCCESS (partial): The error about the job not existing is displayed many times 7. Repeat 3 => SUCCESS: The job ID mentioned on 6 stands as 'finished'. 8. Sign off :-D Discussion: * The `requeue` header I added is correct, but it is the default behavior anyway. I prefered to make it explicit, though. * To avoid that bunch of retries, we should requeue with some delay. I didn't manage to make it work (yet) but there's a 'delay' plugin for rabbit [1]. We already install the 'stomp' plugin in koha-common.postinst. But this plugin requires downloading it. Which would require further investigation. * As Nick and Marcel pointed, we need to revisit the whole architecture, the need of a MQ (DB polling wouldn't have this problem), etc. But that's for another place. [1] https://hevodata.com/learn/rabbitmq-delayed-message/#:~:text=To%20delay%20a%.... Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #20 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Re-enqueue is definitely better than the naive sleep approach, great! It is working nicely in my tests. However I think we should: 1. apply this change to misc/workers/es_indexer_daemon.pl (ideally have the duplicated code moved to Koha::BackgroundJobs but that's for another day) 2. remove the "Job not found" warnings from the logs if the job is actually processed later. 3. correctly handle "Frame not processed". If we are enqueuing a job without correctly encoding the data (not JSON) we will never ack or nack and the worker will get stuck. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #22 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Jonathan Druart from comment #20)

3. correctly handle "Frame not processed". If we are enqueuing a job without correctly encoding the data (not JSON) we will never ack or nack and the worker will get stuck.

Done in previous patch "nack and not requeue if frame is invalid". -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #24 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #23)

(In reply to Jonathan Druart from comment #20)

...

2. remove the "Job not found" warnings from the logs if the job is actually processed later.

Would it make sense to store (in worker memory) the number of tries for a given job? I think so, otherwise we may requeue a job endlessly...

It sounds good. But does it make sense in view of separating the MQ and DB loop as suggested on the omnibus? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #26 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #25)

(In reply to Marcel de Rooy from comment #24)

...

(In reply to Jonathan Druart from comment #23)

...

(In reply to Jonathan Druart from comment #20)

...

2. remove the "Job not found" warnings from the logs if the job is actually processed later.

Would it make sense to store (in worker memory) the number of tries for a given job? I think so, otherwise we may requeue a job endlessly...

It sounds good. But does it make sense in view of separating the MQ and DB loop as suggested on the omnibus?

What do you suggest? We keep it buggy? :)

LOL As you might be aware, the omnibus was created to resolve an enormous bunch of bugs related to this feature. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #28 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Jonathan Druart from comment #20)

2. remove the "Job not found" warnings from the logs if the job is actually processed later.

Done in previous patch "Bug 35819: Improve logging" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #29 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 161624 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161624&action=edit Bug 35819: Adjust es_indexer_daemon -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #31 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #20)

Re-enqueue is definitely better than the naive sleep approach, great!

It is working nicely in my tests.

However I think we should: 1. apply this change to misc/workers/es_indexer_daemon.pl (ideally have the duplicated code moved to Koha::BackgroundJobs but that's for another day) 2. remove the "Job not found" warnings from the logs if the job is actually processed later. 3. correctly handle "Frame not processed". If we are enqueuing a job without correctly encoding the data (not JSON) we will never ack or nack and the worker will get stuck.

I think I missed a lot on this bug conversation :-P Sorry! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #34 from Tomás Cohen Arazi <tomascohen@gmail.com> --- This is NSO but the original patch is SO by a QA team member, and has follow-up patches from two QA team members... This shouldn't block our bugs :-D Testing and adding my QA stamp. -- You are receiving this mail because: You are watching all bug changes.

SELECT * FROM background_jobs; => FAIL: Notice the job ID mentioned on 2 stands as 'new'.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161172|0 |1 is obsolete| | Attachment #161173|0 |1 is obsolete| | Attachment #161267|0 |1 is obsolete| | Attachment #161527|0 |1 is obsolete| | Attachment #161624|0 |1 is obsolete| | --- Comment #35 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 161682 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161682&action=edit Bug 35819: Notify NACK and requeue when Job ID not found This patch makes the worker reject the incoming frame for putting the message back in the queue, in the event the job id doesn't exist yet. Which is the case when some actions are being triggered inside a transaction which hasn't been commited to the DB yet. To test you will need 3 KTD shells (a) mysql: $ ktd --shell k$ sudo koha-mysql kohadev (b) logs: $ ktd --shell # for restarting the worker and looking at the logs k$ sudo koha-worker --restart kohadev ; tail -f /var/log/koha/kohadev/worker-*.log (c) running the test: $ ktd --shell 1. Have (a), (b) and (c) terminals ready 2. On (c), run: $ perl -MKoha::Database -MKoha::BackgroundJob::BatchUpdateBiblioHoldsQueue -e 'Koha::Database->schema->txn_do( sub { Koha::BackgroundJob::BatchUpdateBiblioHoldsQueue->new->enqueue({ biblio_ids => [ 1 ] }); sleep 1; } );' => FAIL: * (b) shows (once) an error about a job not existing 3. On (a) run: 4. Apply this patch 5. Ctrl+c on (b), and re-run to launch the worker with the patch applied 6. Repeat 2 => SUCCESS (partial): The error about the job not existing is displayed many times 7. Repeat 3 => SUCCESS: The job ID mentioned on 6 stands as 'finished'. 8. Sign off :-D Discussion: * The `requeue` header I added is correct, but it is the default behavior anyway. I prefered to make it explicit, though. * To avoid that bunch of retries, we should requeue with some delay. I didn't manage to make it work (yet) but there's a 'delay' plugin for rabbit [1]. We already install the 'stomp' plugin in koha-common.postinst. But this plugin requires downloading it. Which would require further investigation. * As Nick and Marcel pointed, we need to revisit the whole architecture, the need of a MQ (DB polling wouldn't have this problem), etc. But that's for another place. [1] https://hevodata.com/learn/rabbitmq-delayed-message/#:~:text=To%20delay%20a%.... Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #37 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 161684 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161684&action=edit Bug 35819: nack and not requeue if frame is invalid If a frame cannot be correctly processed (most probably because the body is not valid JSON) then we are not acking or nacking the frame and the worker is stuck. In this specific case we should nack without requeuing the frame. NOTE that requeue must be 'true' or 'false', not 1 or 0, or the default 'true' will be used. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #39 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 161686 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161686&action=edit Bug 35819: Adjust es_indexer_daemon Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | Status|Passed QA |Signed Off --- Comment #42 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #41)

Marcel, could you maybe do a final review here?

Sure, will do. Changing status -- You are receiving this mail because: You are watching all bug changes.

SELECT * FROM background_jobs; => FAIL: Notice the job ID mentioned on 2 stands as 'new'.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161682|0 |1 is obsolete| | --- Comment #43 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 161752 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161752&action=edit Bug 35819: Notify NACK and requeue when Job ID not found This patch makes the worker reject the incoming frame for putting the message back in the queue, in the event the job id doesn't exist yet. Which is the case when some actions are being triggered inside a transaction which hasn't been commited to the DB yet. To test you will need 3 KTD shells (a) mysql: $ ktd --shell k$ sudo koha-mysql kohadev (b) logs: $ ktd --shell # for restarting the worker and looking at the logs k$ sudo koha-worker --restart kohadev ; tail -f /var/log/koha/kohadev/worker-*.log (c) running the test: $ ktd --shell 1. Have (a), (b) and (c) terminals ready 2. On (c), run: $ perl -MKoha::Database -MKoha::BackgroundJob::BatchUpdateBiblioHoldsQueue -e 'Koha::Database->schema->txn_do( sub { Koha::BackgroundJob::BatchUpdateBiblioHoldsQueue->new->enqueue({ biblio_ids => [ 1 ] }); sleep 1; } );' => FAIL: * (b) shows (once) an error about a job not existing 3. On (a) run: 4. Apply this patch 5. Ctrl+c on (b), and re-run to launch the worker with the patch applied 6. Repeat 2 => SUCCESS (partial): The error about the job not existing is displayed many times 7. Repeat 3 => SUCCESS: The job ID mentioned on 6 stands as 'finished'. 8. Sign off :-D Discussion: * The `requeue` header I added is correct, but it is the default behavior anyway. I prefered to make it explicit, though. * To avoid that bunch of retries, we should requeue with some delay. I didn't manage to make it work (yet) but there's a 'delay' plugin for rabbit [1]. We already install the 'stomp' plugin in koha-common.postinst. But this plugin requires downloading it. Which would require further investigation. * As Nick and Marcel pointed, we need to revisit the whole architecture, the need of a MQ (DB polling wouldn't have this problem), etc. But that's for another place. [1] https://hevodata.com/learn/rabbitmq-delayed-message/#:~:text=To%20delay%20a%.... Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161684|0 |1 is obsolete| | --- Comment #45 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 161754 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161754&action=edit Bug 35819: nack and not requeue if frame is invalid If a frame cannot be correctly processed (most probably because the body is not valid JSON) then we are not acking or nacking the frame and the worker is stuck. In this specific case we should nack without requeuing the frame. NOTE that requeue must be 'true' or 'false', not 1 or 0, or the default 'true' will be used. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #161686|0 |1 is obsolete| | --- Comment #47 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 161756 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161756&action=edit Bug 35819: Adjust es_indexer_daemon Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Add forgotten module -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #49 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- No problem for me. Get this further now. WARN misc/workers/background_jobs_worker.pl WARN tidiness The file is less tidy than before (bad/messy lines before: 12, now: 15) WARN misc/workers/es_indexer_daemon.pl WARN tidiness The file is less tidy than before (bad/messy lines before: 19, now: 23) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 --- Comment #50 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 24.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable CC| |lucas@bywatersolutions.com Version(s)|24.05.00,23.11.04 |24.05.00,23.11.04,23.05.10 released in| | --- Comment #52 from Lucas Gass <lucas@bywatersolutions.com> --- Backported to 23.05.x for upcoming 23.05.10 -- You are receiving this mail because: You are watching all bug changes.