tree 9325b4791dc998e0b70b158cf058a895b8c06fb5
parent 076e85045628941591b91c244a14cc4ffc57a599
author Edwin Kempin <ekempin@google.com> 1680682779 +0000
committer Edwin Kempin <ekempin@google.com> 1680684811 +0000

Fix async change message that lists owned path on PostReview

Support for posting the owned paths asynchronously when a code owner
approval is applied was implemented by change I129e611af.

At the moment the asynchronous message posting is triggered via the
OnPostReview#getChangeMessageAddOn extension point. This extension point
is intended to let plugins extend the change message that is posted by
PostReview.

Triggering the asynchronous message posting from this extension point
has issues:

* When the asynchronous message posting is triggered PostReview is not
  done yet, i.e. it didn't commit its updates the change meta ref yet.
  This means now there is a race between PostReview and the extension to
  update the change meta ref, which makes it likely that one of the
  updates fails due to LockFailure.

* Since there is a race with updating the change meta ref, the order in
  which the messages are posted is undefined, but we want the PostReview
  message to be posted first.

* If the update that is applied by PostReview fails with LockFailure,
  the whole operation, including the triggering of async message, is
  retried. This can lead to a situation where the change message with
  the owned path is created twice:
  1. posting the async message succeeds, but the update from PostReview
     fails due to LockFailure (e.g. due to the problem described above,
     but LockFailures are also common due to other reasons)
  2. PostReview is retried
  3. posting the update from PostReview succeeds, but triggers the async
     message again which also succeeds (posting the async message is
     also retried on LockFailure, so it will likely succeed if the
     PostReview update is applied first)

Fix this by not triggering the async posting of the owned paths from the
OnPostReview#getChangeMessageAddOn extension point, but from the
CommentAddedListener#onCommentAdded extension point which is only
invoked after the PostReview update has been applied.

Bug: Google b/276879211
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I4d32542457de2f50b25eb7bf57f5f504720131ab