Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 16 14:13

    jason0x43 on master

    Update webdriver versions (compare)

  • Apr 16 14:13

    jason0x43 on gh-pages

    Update assets (compare)

  • Mar 30 17:45
    dependabot[bot] labeled #195
  • Mar 30 17:45
    dependabot[bot] opened #195
  • Mar 30 17:45

    dependabot[bot] on npm_and_yarn

    Bump y18n from 4.0.0 to 4.0.1 … (compare)

  • Mar 30 17:40
    dependabot[bot] labeled #90
  • Mar 30 17:40
    dependabot[bot] opened #90
  • Mar 30 17:40

    dependabot[bot] on npm_and_yarn

    Bump y18n from 4.0.0 to 4.0.1 … (compare)

  • Mar 18 07:44
    Biboba commented #1179
  • Mar 17 01:05
    jason0x43 commented #1179
  • Mar 17 00:59

    jason0x43 on 4.9

    Update dependencies to fix vuln… (compare)

  • Mar 17 00:54

    jason0x43 on master

    fix(leadfoot): handle WD respon… (compare)

  • Mar 14 16:42
    github-actions[bot] labeled #1179
  • Mar 14 16:41
    Biboba opened #1179
  • Mar 10 01:10
    vladikoff closed #864
  • Feb 12 15:48
    jason0x43 commented #1178
  • Feb 12 15:43
    kgibb commented #1178
  • Feb 12 14:35
    jason0x43 commented #1178
  • Feb 12 13:59
    kgibb commented #1178
  • Feb 11 14:01
    jason0x43 commented #1178
Jason Cheatham
@jason0x43
Do you get a stack for the wmic error?
rhpijnacker
@rhpijnacker
^CUnhandled error: { Error: Command failed: wmic PROCESS GET ParentProcessId,ProcessId                          
^C                                                                                                              
    at checkExecSyncError (child_process.js:616:11)                                                             
    at Object.execSync (child_process.js:653:13)                                                                
    at getChildProcesses (c:\pms\src\iscv3\node_modules\@theintern\digdug\lib\util.js:90:28)                    
    at Object.kill (c:\pms\src\iscv3\node_modules\@theintern\digdug\lib\util.js:24:5)                           
    at process.<anonymous> (c:\pms\src\iscv3\node_modules\@theintern\digdug\Tunnel.js:237:58)                   
    at process.emit (events.js:189:13)                                                                          
  status: 3221225786,                                                                                           
  signal: null,                                                                                                 
  output: [ null, '', '^C' ],                                                                                   
  pid: 33508,                                                                                                   
  stdout: '',                                                                                                   
  stderr: '^C' }                                                                                                
(ノಠ益ಠ)ノ彡┻━┻                                                                                                     
Error: Command failed: wmic PROCESS GET ParentProcessId,ProcessId                                               
^C                                                                                                              
  at checkExecSyncError @ child_process.js:616:11                                                               
  at Object.execSync @ child_process.js:653:13                                                                  
  at getChildProcesses @ node_modules\src\lib\util.ts:133:9                                                     
  at Object.kill @ node_modules\src\lib\util.ts:49:2                                                            
  at process.<anonymous> @ node_modules\src\Tunnel.ts:462:31                                                    
  at process.emit @ events.js:189:13
Jason Cheatham
@jason0x43
Ah, ok, that's probably happening because digdug's sigint handler is trying to kill a process that's already been killed. The handler is still resident because Intern is still alive.
Hmmm...so one thing we could try is explicitly cancelling the run task, and possibly the server, when SIGINT happens. Somewhere in executors/Node, maybe in _beforeRun, register a SIGINT handler that will call this._runTask.cancel()and this.server.stop().
rhpijnacker
@rhpijnacker
ok
rhpijnacker
@rhpijnacker
It looks like wtfnode isn't very helpful. When I run it that way, it cleanly exits.
Jason Cheatham
@jason0x43
Are you using it in the same we you'd normally use node (via your test script or npm)?
rhpijnacker
@rhpijnacker
C:\> node node_modules\intern\bin\intern.js config=@local-chrome-headless

vs

C:\> wtfnode node_modules\intern\bin\intern.js config=@local-chrome-headless

the only difference are the extra wtf characters

Jason Cheatham
@jason0x43
Hmmm... But it does hang when you run the first one? (node node_modules ...) I thought it was only hanging when run through npm or via your test script.
rhpijnacker
@rhpijnacker
Yes, also this way
Jason Cheatham
@jason0x43
Oh, yeah, SIGINT with wtfnode will cleanly exit because it calls process.exit. The goal of wtfnode is to indicate what resources are still open when the program exist. Normally it'll just be stdout and stdin. If there are timers or other handles still open, that's the problem.
rhpijnacker
@rhpijnacker
So, what can we conclude from that?
Jason Cheatham
@jason0x43
What did wtfnode show when you ctrl-c'ed?
rhpijnacker
@rhpijnacker
Except for the usual "Do you want to terminate the script (y/n)" nothing
Maybe we should just switch to using wtfnode ;)
Jason Cheatham
@jason0x43
Ideally you should be seeing something like:
10:57:06 ~/Documents/Work/src/intern/intern-44.x !2                                           ▼  npm.registry.local  4.9.0-pre
❯ NODE_PATH=_build wtfnode _build/src/bin/intern.js config=@wd
Listening on localhost:9000 (ws 9001)
Tunnel started
^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Child processes
  - PID 6843
    - Entry point: /Users/jason/Documents/Work/src/intern/intern-4/node_modules/@theintern/digdug/Tunnel.js:231
    - STDIO file descriptors: 28, 30, 32
- Servers:
  - :::9001 (HTTP)
    - Listeners:
      - request: WebSocketServer @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/ws/lib/websocket-server.js:65
  - :::9000 (HTTP)
    - Listeners:
      - request: app @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/express/lib/application.js:617
- Timers:
  - (30000 ~ 30 s) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/_build/src/lib/Test.js:143
  - (5 ~ 5 ms) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/lodash/lodash.js:6646
  - (5 ~ 5 ms) (anonymous) @ /Users/jason/Documents/Work/src/intern/intern-4/node_modules/lodash/lodash.js:6646
rhpijnacker
@rhpijnacker
i'm not seeing any this._runTask in executors/Node
Jason Cheatham
@jason0x43
It's set in the parent class (executors/Executor)
rhpijnacker
@rhpijnacker
Ah, ok
rhpijnacker
@rhpijnacker
Looks like that suggestion to cancel _runTask and stop the server helps.
It still takes 5 sec. for it to actually exit, but at least it does not keep running anymore.
With coverage enabled, it actually takes much longer, and the CPU goes up. So it looks like it still tries to calculate the coverage.
Jason Cheatham
@jason0x43
Progress!
rhpijnacker
@rhpijnacker
FYI: I took another look at Babel and the problems we had with not-inline source maps. Looks like this is a known bug: babel/babel#5261.
Fortunately it also lists a workaround. So that means stripping the sourceMaps run-time will not be needed after all.
Jason Cheatham
@jason0x43
:tada:
rhpijnacker
@rhpijnacker

Do you recognize this message:

SyntaxError: Unexpected token h in JSON at position 0
  at JSON.parse @ anonymous
  @ src\lib\ProxiedSession.ts:152:29
  @ node_modules\@theintern\common\index.js:16:7174
  at process._tickCallback @ internal\process\next_tick.js:68:7
  at Command._callSessionMethod @ node_modules\src\Command.ts:811:11
  at Command.quit @ node_modules\src\Command.ts:1561:16
  at Suite.after @ src\lib\executors\Node.ts:565:28
  @ src\lib\Suite.ts:434:54
  at new e @ node_modules\@theintern\common\index.js:16:5068
  at runLifecycleMethod @ src\lib\Suite.ts:399:13
  at after @ src\lib\Suite.ts:507:13
  @ src\lib\Suite.ts:719:47
  @ node_modules\@theintern\common\index.js:16:6889
  @ node_modules\@theintern\common\index.js:16:7174

This happens every now and then (on BrowserStack and IE11)

Jason Cheatham
@jason0x43
That's happening when the local server is trying to parse coverage data it downloaded from the browser.
It means that whatever it got wasn't valid JSON. Possibly the raw selenium log from BS would show more information.
That error should also ideally be showing some part of the invalid data.
rhpijnacker
@rhpijnacker
In this session I did not request for coverage results. But apparently it still tries to get that from the browser? Does that make sense?
Jason Cheatham
@jason0x43
Coverage data is collected by default unless coverage is set to false. You shouldn't be getting an error in any case, though -- if there was no coverage data available, the request shouldn't return any. Try setting coverage: false in your config. If you happen to see what data cause the error, that would be useful to know so we could fix the underlying issue.
rhpijnacker
@rhpijnacker
Does it have to be false or falsy? I only set coverage to an actual value for other configurations.
The raw selenium logs does not seem to show anything suspicious:
13:04:29.538 DEBUG [WebDriverServlet.handle] - Found handler: fef00a61-78c4-43a9-97df-11ba3c1b0a0e (org.openqa.selenium.ie.InternetExplorerDriverService)
13:04:29.538 DEBUG [WebDriverServlet.lambda$handle$3] - Handler thread for session fef00a61-78c4-43a9-97df-11ba3c1b0a0e (internet explorer): Executing POST on /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute (handler: ServicedSession)
13:04:29.540 DEBUG [Passthrough.handle] - To upstream: {"script":"return (function getCoverageData(coverageVariable) {\n        var coverageData = (function () {\n            return this;\n        })()[coverageVariable];\n        return coverageData && JSON.stringify(coverageData);\n    }).apply(this, arguments);","args":["__coverage__"]}
13:04:29.540 DEBUG [HttpURLConnection.writeRequests] - sun.net.www.MessageHeader@c2cff515 pairs: {POST /session/fef00a61-78c4-43a9-97df-11ba3c1b0a0e/execute HTTP/1.1: null}{Authorization: Basic cnV1ZGdyYXZlc3RlaWpuMTpGMXBReFRIYnk3d3hCZVBkc21IUw==}{Accept: application/json,text/plain;q=0.9}{X-Forwarded-Host: hub.browserstack.com}{User-Agent: axios/0.19.2}{X-Forwarded-For: 194.171.252.100}{x-connid: 21621292158}{BStack-Host: 185.44.130.87}{x-conn: keep-alive}{Content-Type: application/json; charset=utf-8}{Connection: close}{Cache-Control: no-cache}{Pragma: no-cache}{Host: localhost:64856}{Content-Length: 285}
13:04:29.610 DEBUG [HttpURLConnection.getInputStream0] - sun.net.www.MessageHeader@1b0da276 pairs: {null: HTTP/1.1 200 OK}{Content-Length: 77}{Content-Type: application/json; charset=UTF-8}{Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept}{Accept-Ranges: bytes}{Connection: close}
13:04:29.611 DEBUG [Passthrough.handle] - To downstream: {"sessionId":"fef00a61-78c4-43a9-97df-11ba3c1b0a0e","status":0,"value":null}
Jason Cheatham
@jason0x43
false. It can be specifically false, or an array of files or globs.
rhpijnacker
@rhpijnacker
What happens when it is not set in the config? Does it default to false?
Jason Cheatham
@jason0x43
No (hence "Coverage data is collected by default" :smile: )
rhpijnacker
@rhpijnacker
Ah, ok. That's something I would want to definitely fix then.
Jason Cheatham
@jason0x43
It should probably be disabled by default, though. Currently the default is [], which enables coverage collection, but doesn't actually instrument any files.
rhpijnacker
@rhpijnacker
Is there any usecase where that is useful?
Jason Cheatham
@jason0x43
When you've instrumented code using an external tool like nyc
rhpijnacker
@rhpijnacker
Ah, ok
Jason Cheatham
@jason0x43
That could be more clear, too, though. Like, coverage could support false, an array of globs, and something more explicit like 'external' to indicate that coverage data should be collected even though Intern isn't instrumenting any files itself.
rhpijnacker
@rhpijnacker
Even with coverage: false I get this error:
19:35:11 SyntaxError: Unexpected token E in JSON at position 26
19:35:11   at Server.get @ node_modules\src\Server.ts:376:16
19:35:11   at runRequest @ node_modules\src\Session.ts:133:12
19:35:11   @ node_modules\src\Session.ts:167:44
19:35:11   at new e @ node_modules\@theintern\common\index.js:16:5068
Any other ideas?
Jason Cheatham
@jason0x43
It looks like that's something different. Try printing the data that's causing the error so we can see what the problem is.
Dylan Staley
@dstaley

@jason0x43 any idea what I'm doing wrong here?

it("should emit an event on create", function () {
    const { resolve } = this.async();
    articles.events.on("create", () => resolve());
    articles.create({ title: "win" });
});

articles.create asynchronously emits a create event, so I'm essentially just trying to assert that the event is emitted. However, I get what appears to be an Intern error, saying Cannot read property '_resolver' of undefined.

Jason Cheatham
@jason0x43

The return value of this.async is a Deferred object, so it shouldn't be destructured.

const dfd = this.async();
articles.events.on("create", () => dfd.resolve());

You can also use a Promise:

it("should emit an event on create", function () {
  return new Promise(resolve => {
    articles.events.on("create", resolve);
    articles.create({ title: "win" });
  });
});
Dylan Staley
@dstaley
Thanks! The Promise version worked perfectly. The other version still didn't work, but I actually think that's because of how EventEmitter works on Node. It messes with this, so that could explain why it wasn't working.
Jason Cheatham
@jason0x43
this should be fine since you're using a function declaration for your test, but Tests are also passed the current Test object to support arrow function test callbacks (where this isn't applicable), so you can do
it("should emit an event on create", function (test) {
  const dfd = test.async();
Promises are generally simpler unless you need some of Deferred's more complex behaviors, though.
Dylan Staley
@dstaley
@jason0x43 what are your opinions on tools like Playwright? What benefits/drawbacks would Intern gain by using something like that over WebDriver?