Await safety not yet fixed in swing-store/src/snapStore.js for unbalanced if

[erights]

agoric-sdk/packages/xsnap/src/replay.js

Lines 221 to 225 in 293f88e

	if (running && !['command', 'reply'].includes(kind)) {
	// eslint-disable-next-line no-await-in-loop
	await running;
	running = undefined;
	}

The triage currently at #6219 would fix it, with the explanation and code

        // This nested await is safe because "all-branches-balanced".
        //
        // This nested synchronous-throw-impossible await at the top level of
        // the then branch is safe because it is balanced by a
        // synchronous-throw-impossible await at the top level of the else
        // branch. In fact the await in the else branch was introduced for
        // that balance, in order to make this one safe.
        // eslint-disable-next-line @jessie.js/no-nested-await
        await running;
        running = undefined;
      } else {
        // This nested await is safe because "all-branches-balanced".
        //
        // This nested synchronous-throw-impossible await at the top level of
        // the else branch is safe because it is balanced by a
        // synchronous-throw-impossible await at the top level of the then
        // branch. In fact it was introduced for that balance, in order to
        // make the `await` in the then branch safe.
        // eslint-disable-next-line @jessie.js/no-nested-await
        await null;
      }

Most of #6219 consists of commentary or cosmetic code changes, and so can be postponed until after PS0. But this is a safety fix. Whether we should cherry pick it, to get it in before PS0 depends on what the consequences are of not fixing it.

Assigning myself since I have the fix done in #6219 and would do the cherry picking if we decide to do that.

Git blame shows @dckc as the one who should probably investigate this, so I'm assigning to them as well. Feel free to reassign as appropriate of course.

[erights]

With the simpler await safety rule, this issue is obsolete. Closing.