Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 07 22:42
    dependabot[bot] labeled #95
  • Jun 07 22:42
    dependabot[bot] opened #95
  • Jun 07 22:42

    dependabot[bot] on npm_and_yarn

    Bump glob-parent from 5.0.0 to … (compare)

  • Jun 07 22:17
    dependabot[bot] labeled #200
  • Jun 07 22:17

    dependabot[bot] on npm_and_yarn

    Bump glob-parent from 5.0.0 to … (compare)

  • Jun 07 22:17
    dependabot[bot] opened #200
  • Jun 02 02:14

    jason0x43 on 4.9.1

    (compare)

  • Jun 02 02:14

    jason0x43 on 4.9

    Dev dependency updates Updating metadata for 4.9.1 Updating source version to 4.9.… (compare)

  • May 30 13:53
    RoystonS commented #1179
  • May 21 11:27
    afrischknecht closed #1180
  • May 21 11:27
    afrischknecht commented #1180
  • May 21 11:23
    afrischknecht opened #1180
  • May 10 14:14
    dependabot[bot] labeled #199
  • May 10 14:14
    dependabot[bot] opened #199
  • May 10 14:14

    dependabot[bot] on npm_and_yarn

    Bump hosted-git-info from 2.7.1… (compare)

  • May 10 13:38
    dependabot[bot] labeled #94
  • May 10 13:38
    dependabot[bot] opened #94
  • May 10 13:38

    dependabot[bot] on npm_and_yarn

    Bump hosted-git-info from 2.7.1… (compare)

  • May 06 21:42
    dependabot[bot] labeled #198
  • May 06 21:42
    dependabot[bot] opened #198
rhpijnacker
@rhpijnacker
Fixing the WebSocket problem on the Windows Chrome run works nicely!
I suspect there is a similar issue in the dojo loader, since I'm getting a timeout from the loader every now and then:
Suite chrome 76.0.3809.87 on WINDOWS ERROR
Error: timeout
  at makeError @ Delivery\src\libraries\dojotoolkit\dojo\dojo.js:131:15
  @ Delivery\src\libraries\dojotoolkit\dojo\dojo.js:1692:20
Should I try to fix that by tweaking the script loading timeout in BrowserStack?
(Somehow I do not remember this being an issue with Intern 3, I wonder how this is different now...)
Jason Cheatham
@jason0x43
Hmmm...dojo is external to Intern, so there isn't a difference as far as Intern 3 vs 4 goes, and it's request system is entirely separate from Intern's. Intern's server code is different between 3 and 4, though, and dojo is loading files through that, so there could be an issue there.
rhpijnacker
@rhpijnacker
I'll run it a bunch of times on Intern 3 to see if it isn't just that we have more tests than we used to have (when we were still using BrowserStack in regression)
rhpijnacker
@rhpijnacker

When I kill the session on BrowserStack, I eventually get

(ノಠ益ಠ)ノ彡┻━┻
UnknownError: [GET https://(redacted)@hub.browserstack.com:443/wd/hub/session/51f290540ef640dd13ca10181269d3f1cd0fef4f/url] Session not started or terminated
  at Server.get @ node_modules\src\Server.ts:376:16

should that not terminate the Intern run?

Jason Cheatham
@jason0x43
Terminating the session on BS won't immediately stop the Intern run because Intern doesn't know the session was intentionally closed.
rhpijnacker
@rhpijnacker
The error message does suggest that it knows the Session wasn't started, though.
Could we use the WebSocket pinger to detect this and cleanup?
Jason Cheatham
@jason0x43
That error text isn't actually coming from Intern, but we could probably use the status code. Intern currently sends a heartbeat request to keep the session alive if it's idle for a while; that could also be used to detect a downed session.
rhpijnacker
@rhpijnacker
Until now, I've edited node_modules\@theintern\digdug\BrowserStackTunnel.js to enable the info console logger. Is there a less "hacky" way of doing this?
Jason Cheatham
@jason0x43
Adding the capability "browserstack.console": "info" to your environment should work.
rhpijnacker
@rhpijnacker
Oh... that's rather obvious...
Jason Cheatham
@jason0x43
:grinning:
rhpijnacker
@rhpijnacker
Do you know a simple way to retrieve the console log of a unit test running in a browser in the SeleniumTunnel environment? On BrowserStack I can download it from the dashboard, and I'd like to compare this to a local run on the SeleniumTunnel.
Jason Cheatham
@jason0x43
You can use getLogsFor (https://theintern.io/docs.html#Leadfoot/2/api/Command/getlogsfor). Not all browsers support retrieving logs, so your mileage may vary.
rhpijnacker
@rhpijnacker
How can I get a handle to the leadfoot instance?
Jason Cheatham
@jason0x43
It's this.remote
Oh, sorry
You said unit test
Hmmm....
rhpijnacker
@rhpijnacker
Yup
Jason Cheatham
@jason0x43
You could write a simple plugin that would run on the Intern host (so in "node": { "plugins": [...] }) that would listen for the remote session's suiteEnd event. The session suite will have a remote property that you can use to call Leadfoot commands.
"Retrieve browser logs after run" would be a nice general feature to add for unit tests
rhpijnacker
@rhpijnacker
ok, not as simple as I had hoped, but I'll give it a shot.
rhpijnacker
@rhpijnacker
I think I have found a way to circumvent the dojo loader issue: by increasing the waitSeconds dojo configuration property to 120 I'm not getting the error any more.
This did point me at another issue, though: we are using Babel and include the full source code in the sourceMappingURL (which was the only way to get it mapped correctly, IIRC). However, there is little use sending this additional data to BrowserStack every time we run the test suite. Is there a way to remove this line at run-time?
Jason Cheatham
@jason0x43
There isn't currently an automatic way to strip source maps out of code, no. Intern has the infrastructure in place to write custom middleware for its server, which would let you strip that out on-the-fly; it would need to expose some config options to let users actually write middleware. It would probably be cleaner to use separate source maps, though.
rhpijnacker
@rhpijnacker
Yes, I will investigate the latter, but we could not get that running.
rhpijnacker
@rhpijnacker
About the Ctrl-C issue. Do you have any suggestion where to start looking?
Jason Cheatham
@jason0x43
One tool I've used for this sort of thing is wtfnode. You run a program with wftnode, then kill it with ctrl-c, and wtfnode will tell you what resources are still being held open.
I'm still a bit unsure of exactly what's still running. Like, in a functional test run there are normally three processes: Intern (node), Selenium (java), and whatever webdriver is in use (e.g., chromedriver). If there's still a node process running after Intern dies, I'm curious about what it is.
You could also run Intern in debug mode and ensure that you see "Stopping server..." followed by "Stopped http server" and "Stopped ws server".
rhpijnacker
@rhpijnacker
Haha, wtfnode ... hilarious
Jason Cheatham
@jason0x43
:smile:
rhpijnacker
@rhpijnacker
The process that remains running is Intern (node)
I'll give wtfnode a try (when I get around to it)
Jason Cheatham
@jason0x43
But it stopped outputting to stdout, and you got a prompt back?
rhpijnacker
@rhpijnacker
Well, npm gave me the prompt back, but node is still running (and outputting) in the background
Jason Cheatham
@jason0x43
Ohhhhh, it's running behind npm.
rhpijnacker
@rhpijnacker
Yes, (sorry if I hadn't mentioned that before)
Jason Cheatham
@jason0x43
Are you sure that the SIGINT is being received by Intern? There have been a couple of npm issues in the past regarding signals not being forwarded to processes started via npm run.
rhpijnacker
@rhpijnacker
So, there are two ways we are invoking this:
  1. via npm ... it looks like the complete tree is still there (so could be that Intern does not get to see the SIGINT)
  2. via a custom script that spawns node directly, this is similar to when I invoke node node_modules\intern\bin\intern.js ...
    Witch case 2. I can see that the tunnel client processes are cleaned up on Ctrl-C, but then the node process keeps running. I have to kill it by some other means
So, we might be looking at 2 different errors here
Btw. when I Ctrl-C again, it tries to run wmic PROCESS GET ... which fails for some reason. This indicates that the SIGINT handler is still getting called on the next Ctrl-C's
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