Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Process previously failed backfill events in the background #13623

Closed
Tracked by #15182
MadLittleMods opened this issue Aug 25, 2022 · 0 comments · Fixed by #15585
Closed
Tracked by #15182

Process previously failed backfill events in the background #13623

MadLittleMods opened this issue Aug 25, 2022 · 0 comments · Fixed by #15585
Assignees
Labels
A-Federation A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) A-Performance Performance, both client-facing and admin-facing O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@MadLittleMods
Copy link
Contributor

After #13621, we will know if we have previously tried to backfill event and it failed. When we decide to backfill that event again, we should process it in the background so it doesn't block and make /messages slow when we know it will probably fail again.

Follow-up to #13621 and #13622

Part of making /messages faster: #13356

@MadLittleMods MadLittleMods added A-Federation A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) labels Aug 25, 2022
@DMRobertson DMRobertson added A-Performance S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Uncommon Most users are unlikely to come across this or unexpected workflow A-Performance Performance, both client-facing and admin-facing and removed A-Performance labels Aug 25, 2022
MadLittleMods added a commit that referenced this issue Sep 14, 2022
We can follow-up this PR with:

 1. Only try to backfill from an event if we haven't tried recently -> #13622
 1. When we decide to backfill that event again, process it in the background so it doesn't block and make `/messages` slow when we know it will probably fail again -> #13623
 1. Generally track failures everywhere we try and fail to pull an event over federation -> #13700

Fix #13621

Part of #13356

Mentioned in [internal doc](https://docs.google.com/document/d/1lvUoVfYUiy6UaHB6Rb4HicjaJAU40-APue9Q4vzuW3c/edit#bookmark=id.qv7cj51sv9i5)
MadLittleMods added a commit that referenced this issue May 12, 2023
Fix #13623

Follow-up to #13621 and #13622

Part of making `/messages` faster: #13356
@MadLittleMods MadLittleMods self-assigned this May 23, 2023
MadLittleMods added a commit that referenced this issue May 25, 2023
Process previously failed backfill events in the background because they are bound to fail again and we don't need to waste time holding up the request for something that is bound to fail again.

Fix #13623

Follow-up to #13621 and #13622

Part of making `/messages` faster: #13356
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Federation A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) A-Performance Performance, both client-facing and admin-facing O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants