Description

Where: In abstract wiki content pages.

When there is a "high" number of fragments, and a reader/editor selects a language for preview for which the fragments are not cached:

• there are N synchronous calls to the abstract render fragment API, which makes N synchronous calls to wikifunctions, which makes N synchronous calls to the orchestrator.
• from the browser perspective, the calls are blocking, and often end up in timeout, or pool counter exceptions.
• it means that, after being blocked for 10 seconds, all fragments are rendered in errors at the same time, requiring a page refresh.

Desired behavior/Acceptance criteria

Abstract render fragment API should have an async flag, so that

When async=true

• returns fresh cache value if available,
• returns stale cache value if available and enqueues job to re-generate fresh value,
• returns pending response if no fresh nor stale content are available

When async=false

• returns fresh cache value if available,
• returns stale cache value if available and enqueues job to re-generate fresh value,
• makes a sync call to wikifunctions, waits for the response and returns the synchronously rendered fragment

From AbstractPreview component:

• requests should be enqueued and handled in a controlled way: one by one, with rest time between them, and requeued when content is still pending
• there should be a limit on number of tries
• when multiple fragments are requested at the same time (init or set preview language), calls should be async.
• when fragments are requested individually (edit or add new fragment), calls can be made sync.

Completion checklist

• Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Front-end_Task/Bug_Completion_Checklist