feat(preview-enhancement): make background-job interval configurable#12791
feat(preview-enhancement): make background-job interval configurable#12791lubo92 wants to merge 1 commit into
Conversation
|
Thanks for opening your first pull request in this repository! ✌️ |
ChristophWurst
left a comment
ChristophWurst
left a comment
There was a problem hiding this comment.
Looks good, thanks!
This should also be reflected at https://docs.nextcloud.com/server/latest/admin_manual/groupware/mail.html.
|
Agent and model is missing from the commit. See https://github.com/nextcloud/mail/blob/main/AGENTS.md#commit-message-format |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
The PreviewEnhancementProcessingJob is what writes the `imip_message`
flag onto mail_messages rows. Downstream, IMipMessageJob only picks
up messages with that flag set, so the enhancement interval is the
ceiling on how long an incoming calendar invitation can take to turn
into a CalDAV event.
The current hard-coded 3600s is reasonable for bulk-preview enrichment
but way too slow for the iMIP pipeline: small Proton/Fastmail/self-
hosted installs that want invitations to feel live need something in
the 60–300s range. That's a per-setup trade-off (smaller sites have
the headroom, larger ones probably do not), so let's expose the knob
instead of picking one number.
New system config:
occ config:system:set app.mail.preview-enhancement-interval \
--value=300 --type=integer
When unset, keeps the existing 3600s default. A MIN_INTERVAL=60s
floor prevents a misconfigured value from hammering the DB. The job
instance is re-created every time the scheduler enqueues it, so the
new value takes effect on the next tick — no restart needed.
AI-assisted: Claude Code (Claude Opus 4.7)
Signed-off-by: Wolfgang Lubowski <w.lub92@gmail.com>
lubo92
force-pushed
the
feat/configurable-preview-enhancement-interval
branch
from
4bbfde5 to
2432e92
Compare
|
Thanks @ChristophWurst for the review. Rebased on I'll open a follow-up PR against |
| // calendar events). A floor of MIN_INTERVAL keeps a misconfigured | ||
| // value from hammering the DB. | ||
| $configured = $config->getSystemValueInt( | ||
| 'app.mail.preview-enhancement-interval', |
There was a problem hiding this comment.
| 'app.mail.preview-enhancement-interval', | |
| 'app_mail_preview_enhancement_interval', |
New configuration options (that go into config.php) should not use . anymore.
There was a problem hiding this comment.
For new code I would in general prefer IAppConfig rather then config.php. For example like abuse_number_of_recipients_per_message_threshold
3 participants
Why
`PreviewEnhancementProcessingJob` writes the `imip_message` flag. `IMipMessageJob` only picks up rows with that flag set, so the enhancement interval is effectively the ceiling on how long an incoming calendar invitation can take to turn into a CalDAV event.
The current hard-coded `setInterval(3600)` is reasonable for bulk preview-data enrichment, but it's the wrong number if you want iMIP to feel live. On a small Proton/Fastmail/self-hosted install the box has plenty of headroom to run the job every minute or two; on a hoster with 10k mailboxes the same number would be painful.
That's a per-setup trade-off. So: expose the knob.
What
New system config `app.mail.preview-enhancement-interval` (integer seconds).
```
occ config:system:set app.mail.preview-enhancement-interval --value=300 --type=integer
```
Unset ⇒ keeps the current 3600s default. A `MIN_INTERVAL = 60`s floor prevents a misconfig from hammering the DB. The job is instantiated via DI per tick, so the new value picks up on the next scheduler run — no restart required.
Companion PR
Related: #12790 (iMIP detection when `method=` is missing). Together they make Proton-Bridge-delivered invitations flow end-to-end. This PR is independent and valuable on its own.
Checklist
Co-authored-with Claude Opus 4.7.