The request for one row. Mirrors what each LoadItemsTask branch sent, parameter for parameter.

apiPipeline yields such an entry as undelivered, which the row reports as failed.

Transforms one pipeline response and emits its row.

res is invalid when the request never got an answer; an HTTP error (res.ok = false) is folded into the same "failed" status, because neither says what the item HAS. Only an "ok" carries a list the UI may act on, including an empty one.

Finishes a row (ordering, filtering, playlist shape) and appends its carrier.

Everything before the append is thread-local — the item nodes and the carrier belong to this thread until then. The append and the rowReady write are the row's two crossings.

One thread services every extras row an item shows. It replaced a serial chain of one persistent LoadItemsTask per row kind, where each row launched the next from its observer — so row k waited for the SUM of fetches 0..k, and every hop rewrote the RowList's layout after rows already existed, which redraws its row counter.

apiPipeline keeps one request per pool slot in flight on this one thread, so rows now arrive in completion order. Display order is restored by the consumer, which commits nothing until every row has resolved — see ExtrasRowList.commitRows.

Pool readiness: apiPipeline does not wait for the API pool to come up. That is safe here for the same reason it is for LoadLatestRowsTask — ExtrasRowList is only asked to load once ItemDetails holds the item, which arrived through a blocking fetch (loadDetailsTask, or the deep-link resolver), so the pool is provably up.