`OutOfOfficeEventDispatcherJob` is not cleaned up correctly
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
Hướng nghiên cứu
Đọc apps/dav/lib/Service/AbsenceService.php, tập trung vào clearAbsence() và createOrUpdateAbsence(), đồng thời kiểm tra cách IJobList::remove() so khớp các đối số của job. Sau đó, xem lại apps/dav/tests/unit/Service/AbsenceServiceTest.php và bổ sung kiểm thử cho việc xóa một lần vắng mặt và chỉnh ngày thành ngày trong quá khứ. Hoàn thành khi chỉ các job của lần vắng mặt đó bị xóa và không còn job bắt đầu hoặc kết thúc trong quá khứ nào trong hàng đợi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
⚠️ This issue respects the following points: ⚠️
- This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug.
- This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
- I'm using a maintained major version of Nextcloud Server and tested against the latest patch level.
- I agree to follow Nextcloud's Code of Conduct.
- I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description
The OutOfOfficeEventDispatcherJob background jobs, which dispatch OutOfOfficeStartedEvent
and OutOfOfficeEndedEvent, are not cleaned up correctly in OCA\DAV\Service\AbsenceService.
- Clearing an absence cancels the pending jobs of all users
- Editing an absence so a start or end time is already past leaves the old job queued
Clearing an absence cancels the pending jobs of all users
AbsenceService::clearAbsence() calls:
$this->jobList->remove(OutOfOfficeEventDispatcherJob::class);
IJobList::remove() with no argument deletes every job of that class, not only the
jobs of the cleared absence. So one user clearing their absence cancels the queued start and
end jobs of every other user's upcoming or running absence. Those users never get
OutOfOfficeStartedEvent / OutOfOfficeEndedEvent for their absence.
Listeners on those events, such as an app that acts when an absence starts or ends, silently
miss them. user_status is partly protected because UserStatusAutomation also schedules
itself from the absence dates.
Editing an absence so a start or end time is already past leaves the old job queued
AbsenceService::createOrUpdateAbsence() only calls IJobList::scheduleAfter() when the
new start or end time is still in the future. scheduleAfter() updates an existing job with
the same class and arguments (['id' => <absence id>, 'event' => 'start'|'end']), so moving
an absence to other future dates works. But if an edit moves the start (or end) to now or
earlier, no scheduleAfter() call happens and the old job stays queued at its previous time.
When it runs, it loads the absence by id and dispatches a stray OutOfOfficeStartedEvent
(or OutOfOfficeEndedEvent) at the wrong time.
Impact of (2) is low. user_status and Mail just recompute their state from the current
absence data, but listeners that act on the event itself get a stray event.
Steps to reproduce
Problem 1
- As user
alice, set an absence in Personal settings → Availability with a first day in the future, and save. - Confirm two jobs exist for it:
SELECT id, argument, last_checked FROM oc_jobs WHERE class = 'OCA\\DAV\\BackgroundJob\\OutOfOfficeEventDispatcherJob'; - As user
bob, set any absence and save, then click "Disable absence". - Run the query from step 2 again: no jobs are left, and alice's start and end jobs are gone too.
Problem 2
- As user
alice, set an absence from next Monday to next Friday and save. - Confirm the
startjob for that absence id is scheduled for next Monday 00:00 (user timezone). - Edit the absence so the first day is today, and save.
- Run the query again: the
startjob is still scheduled for next Monday. - Next Monday, the job runs and dispatches
OutOfOfficeStartedEventfor an absence that
started days earlier.
Expected behavior
- Clearing an absence only removes the start and end jobs of that absence.
- After editing an absence, no start or end job stays queued for a time that is already past.
Nextcloud Server version
36 (master). Same code on stable32, stable33, stable34 and stable35.
Operating system
Not environment specific (logic bug in apps/dav)
PHP engine version
Not environment specific
Web server
Not environment specific
Database engine version
Not environment specific
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install (present since the feature was added in Nextcloud 28)
Are you using the Nextcloud Server Encryption module?
Not relevant
What user-backends are you using?
- Default user-backend (database) (not backend specific)
Configuration report
Not relevant
List of activated Apps
dav, user_status (default)
Nextcloud Signing status
Not relevant
Nextcloud Logs
Nothing is logged; both problems are silent.
Additional info
Affected code: apps/dav/lib/Service/AbsenceService.php
clearAbsence(): theremove()call without an argument.createOrUpdateAbsence(): start and end jobs are only scheduled when the time is in the future.
Proposed fix: always remove jobs with their exact arguments, for example:
$this->jobList->remove(OutOfOfficeEventDispatcherJob::class, [
'id' => $absence->getId(),
'event' => OutOfOfficeEventDispatcherJob::EVENT_START,
]);
- In
clearAbsence(): remove both jobs (EVENT_STARTandEVENT_END) of the deleted absence. - In
createOrUpdateAbsence(): if the new start or end time is not in the future, remove that job. - Add unit tests in
apps/dav/tests/unit/Service/AbsenceServiceTest.phpfor both cases.
- Ngôn ngữ chính
- PHP
- Star
- 37.2k
- Fork
- 5.3k
- Merge trung bình
- 2 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 676
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của nextcloud/server
-
0. Needs triage 34-feedback bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
nextcloud/server#65904 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
0. Needs triage 36-feedback bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
0. Needs triage 35-feedback bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
0. Needs triage 35-feedback bug team: Files
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: SnowflakeGenerator passes arguments in wrong order to ISequence, causing duplicate IDs in Nextcloud 35Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở0. Needs triage 35-feedback bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
nextcloud/server#65434 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của nextcloud/server
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 71/100
Automattic/blocks-engine#3438 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
getgrav/grav-plugin-api#66 ·
-
Document Laravel 12/13 attributes that work in modules (UsePolicy, ObservedBy, UseFactory, Bind)Đang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
nWidart/laravel-modules#2236 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 1 ngày
-
frontend good first issue healthcare-review
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
AfyaLinkAfrica/afyalink-web#25 ·
Maintainer thường phản hồi trong vòng 1 ngày