commit 6ec4c4477fe2a0429c718f73aa48c46ba0f4fb35
author Edwin Kempin <ekempin@google.com> Fri May 06 15:54:01 2022 +0200
committer Edwin Kempin <ekempin@google.com> Mon May 09 15:10:33 2022 +0200
tree 347bd2850d111287ab605af35a2d49daa2259b45
parent 0c95f8f3faedb4039a79517a784ce98a600a5a9e

Include unsatisfied SRs into new patch set email when change becomes unsubmittable

When a change becomes unsubmittable users want to know which submit
requirements are no longer satisfied.

With this change we extend the email notification that is sent when
creating a new patch set to include the submit requirement that are
unsatisfied due to the creation of the new patch set (e.g. because an
approval got outdated and removed).

Extending the email notification that is sent when replying on a change
with the same information was already done by change Ic1ac9f02f.

To know whether the change got non-submittable by the new patch set and
to include the unsatisfied submit requirements into the email, we need
to have submit requirement results from before and after the update
available which are computed by calling
ChangeData#submitRequirementsIncludingLegacy().

To be able to create the pre-update ChangeData instance when the email
is being sent we capture the old meta SHA1 during the updateChange step
of the BatchUpdateOps. This means the submit requirements for the
pre-update change state are computed at the moment when the email is
being sent (the submit requirements results are not available in the
updateChange step and hence we cannot provide them to the email sender).
Since the evaluation of submit requirements is expensive it is important
that the email sending is done asynchronously, so that the submit
requirement computation doesn't add up to the latency of the user
request, but that's already the case.

The submit requirement results from after the update are already
computed when the change is (re)indexed due to the update. We can get
this updated ChangeData instance that has the submit requirement results
cached in the postUpdate step of a BatchUpdateOp via
PostUpdateContext#getChangeData(Change) and pass them into the email
sender (so that they do not need to be recomputed there).

To avoid synchronization issues between the main thread and the
background thread that's sending the email we only pass immutable
objects to the background thread that are known to be thread-safe.

Including the unsatisfied submit requirments into the email helps users
understand that a change became unsubmittable and what's blocking the
submission now. It would be possible to include further submit
requirement information (e.g. which submit requirements are still
satisfied/unsatisfied, which submit requirements are newly overriden,
forced or failing), but in order to avoid noise in the email
notifications we didn't include it. The email template has access to the
old and new submit requirement results from before/after the update, so
if anyone wants to include more information this is possible by editing
the template.

Change-Id: Ieda1c79f70b762864f60639bd65ca1bec9a64409
Bug: Google b/230443126
Release-Notes: Included unsatisfied SRs into new patch set email when change becomes unsubmittable
Signed-off-by: Edwin Kempin <ekempin@google.com>