Alberto Islas

> And in that case, there's no main document for the row. This aligns with how the appellate website shows it too, and if you look at the top of...

I've submitted a PR in CL where this new parser is used: https://github.com/freelawproject/courtlistener/pull/2413 No more changes were needed here, so once this is merged, I can add a version bump...

Yeah, this can be launched after we move all the documents to Elasticsearch, for now we'll make sure V3 Search API has the same output in all the documents.

I reviewed whether it's possible to retrieve the users who are using the Search API. However, I'm afraid it is not possible to obtain a list of users for this...

One question here, Should we follow a specific order when developing the new, different endpoints for the V4 Search API? According to the plan outlined above, all the new endpoints...

Great! Thank you for your answers. The most complex seems to be RECAP, as it involves various sorting keys, including one that depends on documents. Thus, that'd be the first...

@mlissner working on the serializer for the v4 RECAP Search API I got a couple of questions so far: The serializer is looking like this so far, basically it primarily...

Great, thanks! Some follow-up questions: > The latter. It should be empty like in the front end. Well, in the frontend, the only scenario where dockets do not contain nested...

Yes, this only directly affects requests beyond page one. However, indirectly, I think it can affect all requests. For instance, if 100 users are requesting page 50 at the same...

Regarding this one: Pros: - If we use search_after in the API, we could implement it alongside [CursorPagination](https://www.django-rest-framework.org/api-guide/pagination/#cursorpagination) which aligns with https://github.com/freelawproject/courtlistener/issues/930 - We won't need to perform an additional...