commit 1d8a1a300124497bfa1281c7cdd2946cf083c9b3
author Kamil Musin <kamilm@google.com> Thu Feb 29 14:49:41 2024 +0100
committer Kamil Musin <kamilm@google.com> Mon Mar 04 09:56:47 2024 +0100
tree dbf047d0a5cb6c05df3cad7bace8a26f4b7763b4
parent c79d722b3a50f4280524368c711623df1d48fb35

Address JSON parsing errors on 204 No Content

On various requests Gerrit server returns status 204. For the most part
these are request for which no response is required, however in some
cases that's not true. For methods which sometimes return JSON and
sometimes 204, this results in JSON parsing error, which after recent
refactor is no longer supressed silently.

Looking through all calls of fetchJSON I've found 3 cases where 204 can
be returned and attempted to be parsed
- Endpoints related to edit patchset return 204, if no edit patchset
  exists.
- Account Status/Name/DisplayName/Username and Set Topic, these methods
  return 204 if attempting to remove value, ie. set empty.
- executeChangeAction: this is for executing arbitrary urls with change
  url prefix. Some of the requests don't have a response.

In all above cases previously the logic worked, because the parsing
error would result in returning null value. This was not intended but
happened to work with the old code.

We update all the affected endpoints to inspect response status and
return corresponding correct response or parse the response if needed.

Alternatively we can return undefined from fetchJSON itself,
which would be more consistent with an old behaviour. However undefined
from fetchJSON indicates an error, but in this case the response is not
an error, which can cause confusion.

For executeChangeAction this largely undoes earlier change, that moved
parsing away from gr-change-actions. However this time we only attempt
parsing for the cases where the response is expected.

Google-Bug-Id: b/297849592
Release-Notes: skip
Change-Id: I14bb51becb3a44d4bd32b4beadae5a50ec5e67f4