Await safety uncertain in swing-store/src/snapStore.js

[erights]

agoric-sdk/packages/swing-store/src/snapStore.js

Line 325 in a1dedea

await unlink(fullPath);

The triage at #6219 currently classifies this as

// TODO FIXME This code should be refactored to make this
// await checkably safe, or to remove it, or to record here
// why it is actually safe.

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

[dckc]

I can see how this doesn't clearly match preferred code style, but I don't see evidence of a bug.

If there's a bug, what steps can I take to reproduce it?

[erights]

I can see how this doesn't clearly match preferred code style, but I don't see evidence of a bug.

The evidence is only that there are pairs of stateful code in the immediately surrounding control flow that

• may or may not execute in the same turn
• may be sensitive to the difference.

If there's a bug, what steps can I take to reproduce it?

Look for some way in which the stateful successors of the control flow containing this statement (both the if successor delete call, and the catch clause's delete and push calls) could possibly be sensitive to whether they execute in the same turn as the prior stateful code that may or may not happen in the same turn. If you show that they cannot be sensitive to that, please record your reasoning, add the

    // eslint-disable-next-line @jessie.js/no-nested-await

that reasoning would justify, and make the recorded reason findable from the warning suppression --- either by including it inline, or by recording it elsewhere and then citing it from here.

Or, refactor this code so all this trouble is unnecessary ;)

[erights]

In the absence of such a refutation, please don't close the bug. But if you're confident there is no such case anyway, feel free to declare this bug safely postponable until after imminent milestones, and to remove the "security" label.

[erights]

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