Correct.

@Ottomata By revision ids (as in the example above). Queries are typically for lastest few revisions of a page.

From our end, we do most calls with concurrency. Just wondered, if consolidating models was something being considered.

I see. This could increase API round-tripping by 4x times. Is there work underway to support multi-model, multi-rev-ids in left wing API?

@elukey Correct. Just wanted to add that if with lift wing, we can pass several rev-ids and models at once, like we in the example above, that would be nice.

1. Using just the score stream will not be sufficient for us, since for some conditions we also query scores of certain related revisions of the revision that we see in revision-create stream.
2. We can try this out. As long as we can query scores by project and revisions like ORES, it should be OK.
3. Have to check on this. If revert-risk infers similar idea as that of damaging, it should be fine to swap them.

@elukey We use ores to get damaging and goodfaith scores for each revision that shows up in the revision-create eventstream.
(We then build a structured article object for that revision including scores for that version. These structured articles are used in several of our products - snapshots, realtime stream, article lookup, etc.)

Sounds good.

public key for Prabhat:

QA'd from aws console, gitlab pipeline runs and gitlab settings.
Template for QA saved in enterprise g drive > QA.

In case of redirects, the current gin behaviour is to skip all the global middlewares and redirect directly.