grafana/k6 · error

uploading test: %w

Error message

uploading test: %w

What it means

The `k6 cloud` run path wraps any failure of client.UploadTest in this error. UploadTest POSTs the bundled script archive to the cloud API, so the wrapped error can be a structured ResponseError (auth failure, invalid project), an HTTP/network error (timeout, connection reset), or a body-size rejection. The '%w' keeps the underlying cause attached for inspection.

Source

Thrown at internal/cmd/cloud.go:254

	logger := c.gs.Logger

	// Start cloud test run
	modifyAndPrintBar(c.gs, progressBar, pb.WithConstProgress(0, "Validating script options"))
	client, err := cloudapiv6.NewClient(
		logger, cloudConfig.Token.String, cloudConfig.Hostv6.String, build.Version, cloudConfig.Timeout.TimeDuration())
	if err != nil {
		return err
	}
	projectID, err := prepCloudTestRun(globalCtx, c.gs, client, &cloudConfig, tmpCloudConfig, arc)
	if err != nil {
		return err
	}

	modifyAndPrintBar(c.gs, progressBar, pb.WithConstProgress(0, "Uploading archive"))

	loadTest, err := client.UploadTest(globalCtx, name, projectID, arc)
	if err != nil {
		return fmt.Errorf("uploading test: %w", err)
	}

	if c.uploadOnly {
		et, err := lib.NewExecutionTuple(test.derivedConfig.ExecutionSegment, test.derivedConfig.ExecutionSegmentSequence)
		if err != nil {
			return err
		}
		executionPlan := test.derivedConfig.Scenarios.GetFullExecutionRequirements(et)
		testURL, err := resolveCloudTestURL(cloudConfig.StackURL.String, loadTest.GetId())
		if err != nil {
			return err
		}
		printExecutionDescription(
			c.gs, "cloud", test.sourceRootPath, testURL, test.derivedConfig, et, executionPlan, nil,
		)
		modifyAndPrintBar(c.gs, progressBar, pb.WithConstLeft("Run "), pb.WithConstProgress(1.0, "Archived"))
		c.printTestStatus("Archived")
		return nil

View on GitHub (pinned to 93accf6570)

Solutions

1. Read the wrapped error text after the colon: ResponseError messages name the exact server reason
2. Shrink the archive: remove unused files, use module CDNs, avoid bundling large fixtures
3. Verify token validity and --project-id / K6_CLOUD_PROJECT_ID
4. Increase K6_CLOUD_TIMEOUT if the upload times out on slow links
5. Retry: transient 5xx and connection resets are common for large uploads

Example fix

# before
k6 cloud script.js  # archive includes ./data/10GB.json
# after
echo 'data/*.json' > .gitignore  # or move fixtures out and load at runtime
k6 cloud script.js

var re cloudapiv6.ResponseError
if errors.As(err, &re) {
    switch re.Response.StatusCode {
    case 401, 403: // permanent: fix token, do not retry
    case 413: // permanent: shrink archive
    default: // retry with backoff up to N times
    }
}

When it happens

Trigger: Calling k6 cloud (or the API path UploadTest) when the server rejects the archive upload: 401/403 bad token, 404 wrong project ID, 413 archive too large, request timeout per K6_CLOUD_TIMEOUT, or a network failure between the runner and the API host.

Common situations: Scripts that bundle large assets (node_modules, binaries, big JSON fixtures) exceeding upload limits; expired or revoked API tokens; wrong --project-id; restrictive egress firewalls in CI; slow links hitting the default request timeout.

Related errors

• uploading archive: %w
• upload archive: %w
• missing presigned url in response body
• creating upload request: %w
• archive upload failed: %d %s

AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/41bd2f47d17dbd09. Report an issue: GitHub.