Fragment generators like wikifunctions might not be able to guarantee that they generate their final results within the constraint of a request timeout. So, in the generic case, Parsoid might insert placeholder content for such fragments OR the fragment generator itself might return a placeholder fragment with a cache TTL value (given its knowledge of how long it expects the computation might take).
For ParserOutput objects that contain such page results, we should determine the caching strategy when the page has a known placeholder slot. There are three possibilities:
- Don't cache these pages. If we go this route, we need to work through the performance implications on popular pages, especially around breaking event scenarios. We need to ensure PoolCounters can handle these scenarios.
- Cache these pages with a short generic TTL: We need to determine the TTL value and work through any other followup implications (search results, performance, etc.)
- Let the fragment generator specify a custom placeholder with a custom TTL value. For example, if it knows some computation might take 10 minutes, it might inject an appropriate user message in the placeholder and let the custom TTL eject the page so that a subsequent request to the same page will generate output without a placeholder for this slot.