Make the library asynchronous and compatible with the `async/await` syntax

[Théo Crevon]

Recently, k6 has received support for the async/await syntax. Considering that this javascript library is currently blocking and offers functionalities to users which would benefit from being asynchronous, we should consider making its APIs asynchronous indeed.

This would benefit the users as it would allow to avoid blocking the execution of their scripts over heavy operations such as downloading a file from S3. It would also benefit the overall performance of the scripts relying on AWS operations as it would allow the runtime to offload certain costly operations such as cryptographic signature.

The target API should lead to the following kind of code:

export default async function () {
    // List the buckets the AWS authentication configuration
    // gives us access to.
    const buckets = await s3.listBuckets()

    // If our test bucket does not exist, abort the execution.
    if (buckets.filter((b) => b.name === testBucketName).length == 0) {
        exec.test.abort()
    }

    // Let's upload our test file to the bucket
    await s3.putObject(testBucketName, testFileKey, testFile)

    // Let's list the test bucket objects
    const objects = await s3.listObjects(testBucketName)

    // And verify it does contain our test object
    if (objects.filter((o) => o.key === testFileKey).length == 0) {
        exec.test.abort()
    }

    // Let's redownload it verify it's correct, and delete it
    const obj = await s3.getObject(testBucketName, testFileKey)
    s3.deleteObject(testBucketName, testFileKey)
}

Tasks

Beta Give feedback

1. async signature
2. async S3
3. async SecretsManager
4. async SQS
5. async SSM
6. async KMS
7. async
8. drop the block quote from documentation pages mentioning synchronous behavior

[Théo Crevon]

After running some experiments, it turns out that making the library itself async would be relatively trivial. However, the k6chaijs library doesn't seem to support the expect.to.eventually subset of features. We therefore have a dependency on it, and can't reliably implement support async/await until we get this feature set in k6chaijs.

[Mihail Stoykov]

It might be better to just not use k6chaijs for tests if expect.to.eventually turns out to be too complicated to implement.

[Théo Crevon]

That's fair 👍🏻

I think I'll probably timebox a session trying to integrate the expect.to.eventually syntax to k6chaijs one of these days, and if I don't make enough progress will indeed "just" test the async behaviors without it.