cdk ls -l silently hangs when no default profile

[0xdevalias]

When attempting to call cdk ls -l on a freshly init'd stack, with no default credentials, the program silently hangs.

When repeating the request explicitly passing in my profile, it works as expected:

⇒  cdk --profile devalias ls -l
-
    name: PocAwsCdkStack
    environment:
        name: 123456789012/ap-southeast-2
        account: '123456789012'
        region: ap-southeast-2

I would expect it display some form of descriptive error.

[0xdevalias]

May relate to #130

[rix0rrr]

Can you run the hanging command again with -v and paste the output?

[0xdevalias]

⇒  cdk ls -lv
Command line arguments: { _: [ 'ls' ],
  trace: false,
  strict: false,
  'ignore-errors': false,
  ignoreErrors: false,
  json: false,
  j: false,
  verbose: true,
  v: true,
  'version-reporting': undefined,
  versionReporting: undefined,
  version: false,
  help: false,
  long: true,
  l: true,
  '$0': '/usr/local/bin/cdk',
  app: undefined,
  context: undefined,
  plugin: undefined,
  rename: undefined,
  profile: undefined,
  proxy: undefined }
Defaults: {
  "app": "node bin/poc-aws-cdk.js"
}
Setting "aws:cdk:toolkit:default-region" context to ap-southeast-2
Resolving default credentials

It sits here for a long time.. then eventually:

Unable to determine the default AWS account (did you configure "aws configure"?): { Error: connect ETIMEDOUT 169.254.169.254:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1113:14)
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '169.254.169.254',
  port: 80 }
Setting "aws:cdk:toolkit:default-account" context to undefined
node bin/poc-aws-cdk.js 'base64:eyJ0eXBlIjoibGlzdCIsImNvbnRleHQiOnsiYXdzOmNkazp0b29sa2l0OmRlZmF1bHQtcmVnaW9uIjoiYXAtc291dGhlYXN0LTIifX0='
-
    name: PocAwsCdkStack

That base64 decodes as:

⇒  echo eyJ0eXBlIjoibGlzdCIsImNvbnRleHQiOnsiYXdzOmNkazp0b29sa2l0OmRlZmF1bHQtcmVnaW9uIjoiYXAtc291dGhlYXN0LTIifX0= | base64 -D
{"type":"list","context":{"aws:cdk:toolkit:default-region":"ap-southeast-2"}}

So it definitely sounds like the same timeout type issue that #130 speaks about. Going to close this in favour of that.