Abstract Wikipedia team/Asynchronous content fragments

Draft use cases and their sources

Stack / feed	Use case	Desired outcome	Priority
Web (inc. MF)	User visits a page with an asynchronous fragment that has been rendered.	Page renders immediately to that user, with all content including the fragment.
	User visits a page with an asynchronous fragment that has not yet been rendered.	If logged-out, user is shown an old version of the page as the cache hasn't been invalidated yet.
		Page renders immediately to that user, with a placeholder for the fragment.
		? Page payload includes a listener that updates the page when the placeholder can be replaced.
	User edits a page with an asynchronous fragment that they do not alter.	Page saves and renders immediately to that user and others, including the fragment.
	User edits a page with an asynchronous fragment that they alter.	Page saves and renders immediately to that user and others. The content has an initial placeholder shown for the fragment. At some point later, the fragment is created and the page is re-rendered with the placeholder replaced, and only then is the CDN invalidated. NOTE: Some concept of timeout / error placeholders? Categories for tracking?
	User edits a page with multiple asynchronous fragments that they alter.	Page saves and renders immediately to that user (and others). The content has an initial placeholder shown for each of the changed fragments. The content has the result / value of the fragments that were untouched. As each fragment is created, the page is re-rendered with the placeholder replaced. NOTE: Some form of debouncing, possibly adjustable by the fragment provider/hook?
In-house search	User edits a page with an asynchronous fragment that they alter, then searches for the expected result.	The page's initial placeholder render gets pushed into the search index in the normal way. => At first the search fails, as this has placeholders rather than the final result The page's re-render(s) also get pushed in. [Debouncing?] => Later the search succeeds.
External search feeds	User edits a page with an asynchronous fragment that they alter, then searches DuckDuckGo for the expected result.	At first the search fails, as the page's initial placeholder render is not pushed into the third party search feed(s). Later the search succeeds, as the 'final' (or timeout?) page render does get pushed into the feed.
		? Response to crawler visits to pages that still have placeholders is an HTTP 202 or 203, not 200.
Notifications	User triggers a Notification with an asynchronous fragment in the context.	? Web notifications go out immediately, with the placeholder.
		? Web notifications are updated when the placeholder is replaced in the main render.
		? E-mail notifications go out immediately, with the placeholder, and don't re-render/re-send.
	User triggers a Notification via an asynchronous fragment itself.	Out of scope.
Action API	API content request is made for a page with an asynchronous fragment that has not yet been rendered.	? API response code is an HTTP 202 or 203, not 200.
		? API response for a parse / content request has secondary flags saying this is not complete yet.
MCS API	MCS page request is made for a page with an asynchronous fragment that has not yet been rendered.	? API response has a secondary 'partial' flag saying this is not complete yet.
		? MCS listens (how?) for a content re-render and updates / evicts its cache.
Native apps	User visits a page with an asynchronous fragment that has not yet been rendered.	? Apps show a sign that the content they got back from MCS has a 'partial' flag on it.
REST API	API content request is made for a page with an asynchronous fragment that has not yet been rendered.	? API response code is an HTTP 202 or 203, not 200.
		? Additional call-back endpoint is provided for given revisions when their render is final.
Enterprise	???	???