Async/await debugging jumping

[amcdnl]

I'm having spotty debugging experiences when I try to debug code with async/await using transform-async-to-generator babel plugin ( although I've tried almost every other combination ).

Essentially code with a await will skip to the end of the method and then go into the compiled code. video

    export class Cat {
        async meow(){
            let p = await this.bat(); // <<<< this line runs
            this.fart(); // <<<< then skips this line
            return p;  // <<<< and goes to this line ( always last line in fn )
        }
    }

If you take a look at the generated code for that function:

    meow() {
        var _this = this;

        return _asyncToGenerator(function* () {
            let p = yield _this.bat();
            _this.fart();
            return p;
        })();
    }

its no wonder regarding the results but source maps should handle this, right?

I've tried this with a variety of setups ( require hook / babel-node / babel cli / gulp babel ) and get same issue. I'm using: Node 5.4.0 and Babel 6.4.0

I've created a demo project on github. I've also posted the question on the babel thread.

[jlongster]

Can you try in Firefox and see if it results in the same behavior?

Most likely, this is faulty source-map construction and not the fault of the lib itself. The compiler needs to give this lib correct information for it to work right.

[amcdnl]

I'm running in Node... I see it in Node-Inspector, VSCode Debugger and Webstorm Debugger. I'll try to replicate in browser though.

[fitzgen]

This issue would really benefit from a reduced test case and a link to https://sokra.github.io/source-map-visualization/ with the reduced test case's source map loaded.

[marjan-georgiev]

Here's an example:

export class MyClass {

  async foo() {
    console.log('1. calling bar');
    let result = await this.bar();
    console.log('4. promise resolved');
    console.log('5.', result);
    return result;
  }

  async bar(){
    console.log('2. returning promise');

    return new Promise((resolve, reject) => {
      setTimeout(() => {
        resolve('hello')
      }, 1000);
    });
  }
}

let ob = new MyClass();
ob.foo();
console.log('3. continuing execution...')

Here is the the sourcemap visualization for it: LINK

[fitzgen]

Your link isn't working for me, but I tried myself on that test case and it looks alright in the visualizer

Looking in some more...

[fitzgen]

The test case won't compile for me with babel-plugin-transform-regenerator.

[marjan-georgiev]

That's pretty much the same sourcemap output I'm getting. Try debugging and setting a breakpoint on the line with the await call.
If you go to the next line from there, it will skip to the last line of the foo function.

What I would expect instead is to either

• stay and wait while the promise resolves and go to the line after the breakpoint, or
• go directly to the last line of the file, after the call of ob.foo(), as that's what happens when await is hit.

[fitzgen]

Setting a breakpoint on which line?

[marjan-georgiev]

let result = await this.bar();

[fitzgen]

This is largely working as I expect in Firefox's debugger. Nor is this an issue with the source-map library.

If you go to the next line from there, it will skip to the last line of the foo function.

That's because you are exiting that frame when you yield (or await). Any other JS could run in between and it might throw exceptions or hit other breakpoints, etc.

stay and wait while the promise resolves and go to the line after the breakpoint

The debugger could choose to set a temporary breakpoint for when control returns to the generator/async function, so you can "step over" asynchronous things. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1238745 for that behavior in Firefox. But again, this is not a bug with the source-map library.

[amcdnl]

@fitzgen Thanks for the feedback! Wasn't sure where it should land, i side with the temporary breakpoint!

[dmikov]

I understand that await releases the frame, so is await in .net releases thread. But it doesn't jump the hell away from it. As far as control flow of function under debugger goes it's linear, it really is NOT on the bottom skipping previous statements. The way it currently looks.
In reality while something could happen, nothing else happens on other threads.

[talarari]

hey, any update on this?
source maps are incorrect so debugging doesn't work well, see
microsoft/vscode#19973