Be cognizant of the lifetimes of variables being used to support methods with long execution times
I've been working with the Web Audio API and I made a series of calls like this:
sl := TStringlist.Create;
// fill sl with some data
await( LoadBuffers( sl ) );
await( PlayBuffers( sl ) );
sl.Free;
The call to sl.Free occured before the last buffer had finished playing, even though the await did its job correctly. As a result, when the buffer finished playing and the internal logic continued on to resolve the last track, it blew up because the list of buffers it was given was now empty. In fact, it was gone! But the reference to it still worked enough to say that the .Count value was zero, and it threw an error that was totally unexpected.
The moral of the story here is this:
if you are working with things that can take a lot of time to run (many seconds) and they depend on data in a buffer, then make sure that said buffer has a lifetime that goes beyond the actual clock-time needed to complete the entire operation.
The above block of code makes perfect sense in the VCL world, but may be subject to a time-warp of sorts in the WEB Core world. 
In this case, the await releases after the buffer starts playing, not after it completes.