perf(jobs): run preview pre-warm daily, time-insensitive - #13619
perf(jobs): run preview pre-warm daily, time-insensitive#13619ChristophWurst wants to merge 1 commit into
Conversation
PreviewEnhancementProcessingJob fired hourly per account. It can't be scaled per activity — run()-time setInterval() isn't persisted, so the constructor interval governs pickup — and previews are already computed on demand when a mailbox is opened, so the background job only backfills. Run it once a day and mark it time-insensitive so it can be deferred under load. Assisted-by: ClaudeCode:claude-opus-4-8 Signed-off-by: Christoph Wurst <1374172+ChristophWurst@users.noreply.github.com>
|
Tricky. Why would it be an issue to run this job every 5 minutes? The delay for imip is indeed critical and something a lot of user's flagged even in current version with rather short delay (at best 10min). You see the email in the inbox, but no event in calendar. We discussed to trigger the processing of an imip message when a message is opened in the web client, but that is still todo. As far as I recall is imip is only set through the PreviewEnhancementProcessingJob, and hence running it once a day is an issue for the imip processing. More important for PreviewEnhancementProcessingJob is to actually add a limit (c.f. #13391) to avoid that adding a new mailbox causes a lot load. Do you have any data, why it was recommended to run this job only once per day? |
|
The implication with the delayed imip flagging is true. Also noted that in the PR description. It's a trade-off.
Suggested internally because this was the most executed background job during a 1h30m high server load period. |
PreviewEnhancementProcessingJob fired hourly per account. It can't be scaled per activity — run()-time setInterval() isn't persisted, so the constructor interval governs pickup — and previews are already computed on demand when a mailbox is opened, so the background job only backfills. Run it once a day and mark it time-insensitive so it can be deferred under load.
Assisted-by: ClaudeCode:claude-opus-4-8
Critical implication: this means that imip invitations might be processed delayed by up to a date. The mechanic is that the preview processing job find out if an email is an invitation. It will flag it. The imip job that runs every 5min will then pick it up. If the flagging is delayed so is the actual processing.
🤖 AI (if applicable)