Puppet mutliline syntax errors with a "double at" are not caught

[mysticmcj]

I've been missing a ton of stupid syntax errors lately that show up if I manually run "puppet parser validate filename" and I think it is because puppet is spitting out multiline errors with two "at"s in them.

[mysticmcj]

Example error message:

Error: Could not parse for environment production: Syntax error at ',
      ' at /Users/mcj/projects/sussex/puppet-configs/environments/aws/modules/loadbalancer/manifests/secure.pp:75:27

Example of the bad syntax that caused this:

    options           => {
        'check          => '',
    }

The parser is running... Output from :mes

"./secure.pp" 91L, 2663C                                                                                                                             
syntastic: 0.025273: &shell = '/bin/bash', &shellcmdflag = '-c', &shellpipe = '2>&1| tee', &shellquote = '', &shellredir = '>%s 2>&1', &shellslash = 0, &shellte
mp = 1, &shellxquote = ''
syntastic: 0.025410: UpdateErrors (auto): default checkers
syntastic: 0.025618: CacheErrors: default checkers
syntastic: 0.025984: g:syntastic_aggregate_errors = 1
syntastic: 0.026086: getcwd() = '/Users/mcj/projects/sussex/puppet-configs/environments/aws/modules/loadbalancer/manifests'
syntastic: 0.027294: CacheErrors: Invoking checker: puppet/puppet
syntastic: 2.319137: SyntasticMake: called with options: {'errorformat': '%-Gerr: Try ''puppet help parser validate'' for usage,%-GError: Try ''puppet help pars
er validate'' for usage,%A%t%*[a-zA-Z]: %m at %f:%l:%c,%A%t%*[a-zA-Z]: %m at %f:%l', 'makeprg': 'puppet parser validate --color=false ./secure.pp'}
syntastic: 3.914738: getLocList: checker puppet/puppet returned 1
syntastic: 4.316095: CacheErrors: Invoking checker: puppet/puppetlint
syntastic: 4.316509: SyntasticMake: called with options: {'errorformat': '%t%*[a-zA-Z] %m at %f:%l', 'makeprg': 'puppet-lint --log-format "%{KIND} [%{check}] %{
message} at %{fullpath}:%{line}" ./secure.pp'}
syntastic: 4.472475: getLocList: checker puppet/puppetlint returned 1

SyntasticInfo

Syntastic version: 3.6.0-86 (Vim 703, Darwin)
Info for filetype: puppet                                                                                                                            
Global mode: active
Filetype puppet is active
The current file will be checked automatically
Available checkers: puppet puppetlint
Currently enabled checkers: puppet puppetlint

Relevant .vimrc

set statusline+=%{SyntasticStatuslineFlag()}
let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1
let g:syntastic_check_on_open = 1
let g:syntastic_check_on_wq = 0
let g:syntastic_enable_perl_checker = 1
let g:syntastic_aggregate_errors = 1
let g:syntastic_puppet_puppetlint_quiet_messages = { "level" : "warnings" }
let g:syntastic_debug=1
let g:syntastic_exit_checks=1

[lcd047]

Please post a complete test file that produces these "bad" errors. I can't seem to obtain the error you mention with the piece o code above, and puppet 4.1.0.

[mysticmcj]

class loadbalancer::secure (
  $backendsrv = [],
  $backendip = [],
  $haproxydir = '/var/lib/haproxy',
  $ssldir = "/etc/ssl",
  $sslcert = 'combined.pem',
) {

  file { "${ssldir}/${sslcert}":
    source => "puppet:///modules/loadbalancer/${sslcert}",
    owner  => 'root',
    group  => 'root',
    mode   => '0750',
  }

  class { 'haproxy':
    require                       => File["${ssldir}/${sslcert}"],
    package_ensure                => 'latest',
    service_ensure                => true,
    global_options                => {
      'chroot'                    => $haproxydir,
      'user'                      => 'haproxy',
      'group'                     => 'haproxy',
      'log'                       => 'logsrv:514 daemon notice',
      'daemon'                    => '',
      'pidfile'                   => "${haproxydir}/haproxy.pid",
      'ssl-default-bind-ciphers'  => 'AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!LOW',
      'stats'                     => "socket ${haproxydir}/stats",
    },
    defaults_options =>  {
      'log'          => 'global',
      'stats'        => 'enable',
      'retries'      => '3',
      'option'       => [
        'redispatch',
        'forwardfor',
        'http-server-close',
      ],
      'no option' => [
        'accept-invalid-http-response',
      ],
      'timeout'   => [
        'client 900s',
        'server 900s',
        'check 5s',
        'connect 10s',
        'http-request 10s',
        'queue 1m',
      ],
      'maxconn' => '4000',
    }
  }
  haproxy::listen { 'clearforwarder':
    bind     => {
      ':80'  => [],
    },
    options  => {
      reqadd =>  'X-Forwarded-Proto:\ http',
    }
  }
  haproxy::listen { 'securelistener':
    bind     => {
      ':443' => ['ssl', 'crt', "${ssldir}/${sslcert}", 'no-sslv3', 'no-tlsv10', 'no-tls-tickets'],
    },
    options  => {
      reqadd =>  'X-Forwarded-Proto:\ https',
    }
  }
  haproxy::balancermember{ "${backendsrv}-clear":
    listening_service => 'clearforwarder',
    server_names      => $backendsrv,
    ipaddresses       => $backendip,
    ports             => '80',
    options           => {
      'check          => '',
      'httpchk'       => 'GET / HTTP/1.1\r\nHost:\ testhost',
    }

  }
  haproxy::balancermember{ "${backendsrv}-secure":
    listening_service => 'securelistener',
    server_names      => $backendsrv,
    ipaddresses       => $backendip,
    ports             => '80',
    options           => {
      'check          => '',
      'httpchk'       => 'GET / HTTP/1.1\r\nHost:\ testhost',
    }
  }

}

Throws this on parser validate:

Error: Could not parse for environment production: Syntax error at ',
      ' at /Users/mcj/projects/sussex/puppet-configs/environments/aws/modules/loadbalancer/manifests/test2.pp:75:27

[lcd047]

Right: I can reproduce the problem now, but I'm not sure how to deal with it. The error message includes everything from the last quote on line 75 to the first quote on line 76, including the newline. Basically there can be anything there, I don't think there is any reasonable way to recover that as a normal error.

[mysticmcj]

I was attempting to patch this myself, and I couldn't think of a reasonable way either. It's a bit of an edge case, but one I seem to encounter often. I've had a few recurring errors that haven't been caught -- I suspect that they are all variants of this, but if I see anything else, I will provide info.

[lcd047]

Your best bet is probably to lobby the puppet developers to sanitize their error messages (removing all control characters would be a good start). Better yet, they could add an option to output the errors in a machine-friendly format (JSON would be nice), but I'd say that's unlikely to happen.

As for other failing cases, there might well be. IIRC I dug through the puppet error functions at some point, prompted by a similar problem. I fixed the problem at the time, but there's no telling what else might lie hidden there. :)