Because the ETag cache stores the parsed objects of JSON responses,
cache hits from separate change detail requests could result in the same
object reference. This caused a subtle bug in the gr-change-view's
`_changeChanged` observer method which computes the default patch range
for a change if the range is otherwise unspecified.
This means that reloads of the change view that result in ETag hits for
the detail request, but do not explicitly specify a patch range will not
fire `_changeChanged` and will not correctly update their patch range when
the change loads.
This was first observed in issue 7027 for which I68fa2b82ff was a fix.
In this case, the soft reload failed to update the patch range and the
diffs were set to use `undefined` for the `patchNum`. Reloading in this
configuration would result in a 404 request. Because this was observed
shortly after the project-URL update, it was exacerbated by URL-upgrades
setting `app.params` too frequently. The fix in I68fa2b82ff was to move
some default `patchNum` computation logic out of a special case an into
a general case.
Unfortunately, the generalized default `patchNum` logic depended on
the full set of patches for the change, which was known already only in
the special case from which it was moved. In this way, the change view
would sometimes choose the default `patchNum` based on the change being
navigated away-from rather than the change being navigated to. If the
old change had more patches than the new change, the result would be
selection of a nonexistent patch on the new change.
With this change, following the revert of I68fa2b82ff -- whereby the
default patch selection logic is restored to its special case -- the
ETag decorator is updated to deep clone cache hits for object responses
so that it will not yield equal object references.
Bug: Issue 7027
Change-Id: I9d16616ccf5289c1ba06a6dd5b5174e2452b1352
83060bbce4