Forcing them all into the same paragraph means that the entire thing has to complete within all the time limits. Pragmatically it's easier to call each sentence separately, and squeeze sentence spacers in between them.

An amazing outcome would be to treat compositions in AW not as single calls. Instead gradually resolve them from the inside out, caching along the way, and giving each new level its full time allocation. Then could safely switch to back to paragraph from sentence.

This is related to https://phabricator.wikimedia.org/T431734.

In T432021#12117666, @99of9 wrote:

An amazing outcome would be to treat compositions in AW not as single calls. Instead gradually resolve them from the inside out, caching along the way, and giving each new level its full time allocation. Then could safely switch to back to paragraph from sentence.

We will soon work on memoization, which will handle this but in a very ugly way: the intermediate cached results would only be accessible in subsequent calls, so one would have to "prime" the orchestrator by calling it multiple times. I like the idea of gradual resolution in a single call, but then we'd have to reduce the amount of parallelism, with very bad consequences for latency. Perhaps there's a middle ground (an optional toggle for parallel vs. sequential modes)?

IMO uncontrolled parallelism is causing more problems now that anything else. T430898

But in any case, I'm not suggesting making the entire article sequential, just the calls within calls on AW. It's rare that they have greater than depth 3 or so, and are normally not branching.

In T432021#12125377, @Jdforrester-WMF wrote:

To achieve this we may need to force naïve Wikidata fetches into more specific, targeted, less blow-up-the-orchestrator ones (once they exist).

In the example at the top of this thread, I'm not aware of any naïve fetches. These are important functions, so I'd be happy to work on them if anyone is aware of a problem. They are likely not optimised for efficiency with code helpers etc, but they're also not fetching whole items.

In T432021#12148491, @99of9 wrote:

IMO uncontrolled parallelism is causing more problems now that anything else. T430898

But in any case, I'm not suggesting making the entire article sequential, just the calls within calls on AW. It's rare that they have greater than depth 3 or so, and are normally not branching.

Yes, I think we just need to gate our evaluator fetches so that only a certain number is in flight at a time, rather than straight-up failing. I am writing up a task for this.