Update Sobek and fix http.File to not use []byte

[mstoykov]

What?

Update Sobek

Why?

Sobek updates bring fixes from goja for:

• nesting of destructuring with arrays
• using slices from go code in js code

Also fix for async errors in modules triggering the promise rejection tracker as well, which will be needed for top-level-await

The changes to handling of slices did break some tests and showcased that k6 was handling http.File().data badly. Previously it was []byte which it really shouldn't be.

This fix makes certain that the provided input is string or ArrayBuffer and keeps it that way until it needs to be written.

This aligns with the documentation as well as removes a source of pure []byte in js code which there shouldn't be any.

Separate PR should be made to drop being able to use common.ToBytes with []byte as that should never happen and should be 100% a bug.

Also made the go code return a pointer as that just makes sense instead of a struct that will get copied.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

[oleiade]

Cheers for the detailled explanation 🙇🏻

[manjunadh5369]

import { FormData } from 'https://jslib.k6.io/formdata/0.0.2/index.js'

Let documentFile = http.get( )

const fd = new FormData();
fd.append('file', http.file(documentFile.body, ${<file Name>}, 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'));

let response = http.put(, fd.body(), {headers: {Content-Type': 'multipart/form-data; boundary=' + fd.boundary}})

The documentFile.body is fetched from the first API, then passed as a file using http.file() in the FormData for the second API request.

While this approach works as expected in the open-source k6 environment, it fails in Grafana Cloud with the error message indicating that the document file appears corrupted and cannot be loaded. Error: {"statusCode":406,"error":"Not Acceptable","message":"The document appears to be corrupted and cannot be loaded."}

It appears that there may be a discrepancy in how file uploads are handled between the open-source version of k6 and Grafana Cloud, particularly after the recent release. Any guidance or updates regarding this issue would be greatly appreciated.

[mstoykov]

@manjunadh5369 does it work locally with the latest k6 version v0.55.0 ?

[manjunadh5369]

@mstoykov Oh, I just verified that my local k6 version was not upgraded as I initially thought—it’s still running on v0.51.0. I’ve since upgraded it to the latest version, v0.55.0, and unfortunately, the issue persists locally as well.

Could you please assist me with steps or guidance on how to make this work as it did with the older version? Any help would be greatly appreciated!

[mstoykov]

My expectation is that if you set the response to be binary on the request getting the document it will work again.

Can you try it?

You need to set the request params to have responseType equal to binary

[manjunadh5369]

Thank you very much @mstoykov! It's working now.

[mstoykov]

Glad I could help.

To be honest I expect that before that thsi request was jsut a touch corrupted as going to string and back to binary as you did before this last change likely broke the file underneed.

I guess your API either doesn't check the send API that carefully, you were very lucky for the transition to be lossless, or the response is actually text and your API just expects it as binary data for some reason.