-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3Client returns null when K6_DISCARD_RESPONSE_BODIES
is set to true
#45
Comments
Thanks for surfacing this issue on GitHub! I ran into this problem and it caused me to spin for quite a while thinking that there was either a bug with the client or a problem with my AWS config. I added the following code to my
This ran without any issue, and resulted in the following log in the k6 output:
I also tested the |
Thank you for creating the issue. Things I need to prepare to reproduce:data.jsonThis is the test data stored in S3. actually larger size.
script.jsI set this in a ConfigMap in Kubernetes. Writing the whole ConfigMap feels redundant and informational, so I'll only share the script.js.
k6.yamlThis may not be necessary for some people. I happened to be using K6 Operator. I'm just posting here with the intention of sharing how the environment variables are set in my repro environment.
result:K6 console.log
If I remove If I am missing any information, please let me know. Thanks. |
Thanks a lot for you input 🙇🏻 We have investigated the issue and found a workaround: to ignore the We're looking into the best ways to integrate that change in the library, and a fix should land with version |
Gave this a stab, and couldn't get to a satisfying solution yet. Moving this to 0.9.0. |
Fixes grafana#45
Fixes grafana#45
from #105 (comment)
This one seemed straight forward to me. If i am calling |
This allow us to ignore k6's discardResponseBodies in the context of jslib-aws. As it is mostly a utility library, users have been mostly about having the ability available. See #45 for details. Using the baseRequestParams we set the default responseType for children implementation, allowing us to effectively disregard the http discardResponseBodies option. We can still, locally override it where necessary, as in S3Client.getObject for instance.
We have opened a PR #114 in an attempt to address this issue. If any of you folks have the capacity to take it for a spin, and let us know if it works for you, we would very much appreciate it 🙇🏻 To do so, simply checkout the PR, run import http from 'k6/http'
import { AWSConfig, S3Client } from '../dist/s3.js'
const awsConfig = new AWSConfig({
region: __ENV.AWS_REGION,
accessKeyId: __ENV.AWS_ACCESS_KEY_ID,
secretAccessKey: __ENV.AWS_SECRET_ACCESS_KEY,
sessionToken: __ENV.AWS_SESSION_TOKEN,
})
const s3 = new S3Client(awsConfig)
export default async function () {
// List the buckets the AWS authentication configuration
// gives us access to.
const buckets = await s3.listBuckets()
console.log(JSON.stringify(buckets))
const responseWithBody = http.get('https://httpbin.org/get')
console.log(responseWithBody.body)
} |
* Add baseRequestParams to AWSClient This allow us to ignore k6's discardResponseBodies in the context of jslib-aws. As it is mostly a utility library, users have been mostly about having the ability available. See #45 for details. Using the baseRequestParams we set the default responseType for children implementation, allowing us to effectively disregard the http discardResponseBodies option. We can still, locally override it where necessary, as in S3Client.getObject for instance. * Adopt AWSClient.baseRequestParams in AWS client classes * Update src/internal/client.ts Co-authored-by: Joan López de la Franca Beltran <5459617+joanlopez@users.noreply.github.com> --------- Co-authored-by: Joan López de la Franca Beltran <5459617+joanlopez@users.noreply.github.com>
A user recently reported the following issue in the k6 open-source support forum:
We should run an investigation on this, and figure out if this is the intended behavior, or if we need to adjust the behavior of the jslib.
The text was updated successfully, but these errors were encountered: