tree 467ce945b25e13518fe0de03420c60ed970b24a6
parent 2d29658dc8f4e6f60d751ba558a8e5cc41e86c4c
author Edwin Kempin <ekempin@google.com> 1718270849 +0000
committer Edwin Kempin <ekempin@google.com> 1718275163 +0000

Remove etags for ListFiles REST endpoint

Change Ia92fbad2a and change Ic54db5dc9 remove etags for change and
revision resources because the etag computation is too expensive to
bring any latency benefits. The same is true for the ListFiles etag,
i.e. it includes the expensive change and revision etag computation.

An etag is only returned if the REST endpoint returns a response with
cache control, see RestApiServlet#configureCaching which calls
RestApiServlet#addResourceStateHeaders that sets the etag in the
response. For ListFiles this is only the case if a concrete revision
number is specified, but not for the magic "current" revision.

Etags are mostly relevant for UI's that do auto-refreshing via polling.
PolyGerrit uses the ListFiles REST endpoint (with a concrete revision
number) but fetches the file list only once when the change is loaded
and then doesn't do any polling for it, i.e. it never makes use of the
etag that is returned by ListFiles. For other callers (mostly service
users) it's unlikely that they do polling with etags, especially since
the etag support for this REST endpoint is not even documented [1].
Hence having ListFiles return etags likely doesn't have any benefits,
but calculating them can add up to 1.2s to ListFiles requests, just for
including the etag into the response.

[1] https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#list-files

Release-Notes: Removed etags for ListFiles REST endpoint
Bug: Google b/336400432
Change-Id: Ib49748bfbdde6c69cf215a95c8edbdc33f9db4a8
Signed-off-by: Edwin Kempin <ekempin@google.com>