Explain `EOF`

[olegbespalov]

What?

We should create a documentation page explaining the EOF cases.

Why?

EOF is hard to debug and is not evident to the customers. So the excellent article should serve as a good explanation of why & where they can happen.

[immavalls]

This would help https://community.k6.io/t/erro-0004-syntaxerror-eof/5823, for example.

[immavalls]

@olegbespalov Can I help with this one? I find other forums could benefit, potentially https://community.k6.io/t/xk6-elastic-extention/6649/3. And I'm trying to figure out how to help in these situations. We can chat, and I can do the writing if that helps. It's good learning for me.

[olegbespalov]

@immavalls sure, let's sync up on it next week 👍

[immavalls]

A bit of summary after discussing with @olegbespalov. Feel free to comment!

The typical SyntaxError: EOF at parse (native) comes from goja and golang.

This case is misleading, as this EOF does not always surface the actual error. @olegbespalov opened https://github.com/dop251/goja/issues/503for goja to surface the it.

The most common case is a JSON that is incorrect/corrupt. In k6 it can be reproduced with an attempt to parse an incorrect JSON:

export default function() {
  const data = JSON.parse('{');
}

A run of the script will return:

ERRO[0000] SyntaxError: EOF
        at parse (native)
        at script.js:2:28(4)  executor=per-vu-iterations scenario=default source=stacktrace

We've seen cases where adding a sleep() seemed to help. This could still be the same underlying reason. In this example we suspect that the SUT is under load and returns either incomplete JSON that then fails to parse. Reducing the load with a sleep might have eliminated the error. This is also very typical that the error is caused by the SUT having issues keeping up with the load, or network bottlenecks.

In the case of Elasticsearch reported in https://community.k6.io/t/xk6-elastic-extention/6649/3 we needed more information: we should see the script and where it fails in the script. The problem could be similar, with golang trying to parse what considers a corrupt or incomplete JSON response from Elasticsearch. Or it could be when sending or reading a JSON, unrelated to the output.

Of course, we could also be in the case of a real EOF.

To summarize, while we wait for the outcome of https://github.com/dop251/goja/issues/503, we'll keep an eye on similar topics to check if this is the usual case.

Using k6 --verbose might not help here, but we can try.