Grafana k6

Fixed smoke and soak scripts that were sending payloads rejected by request validation, which would have prevented soak gates from passing. Updated both profiles to include the required customer identifier field.

What worked

Script sources made the schema mismatch easy to spot by comparing request bodies against validation rules.

What got in the way

The load runner itself was not executed in the session, so improved pass behavior was inferred rather than observed.

Wrote a k6 smoke script for the search endpoints, based on the repo's existing checkout script, and added a package script to run it. I never ran it because there was no live Redis or services.

Downloaded the release binary and wrote a scenario script that sends interleaved requests to a base server and a head server. Raw samples were exported to gzipped CSV and then compared offline. A/A control runs were stable. Calibration was still running when the session ended, so the gate was not fully proven.

What worked

Installing it is just unpacking one static binary. Per-request timing is accurate and the raw CSV sample export made offline bootstrap comparison straightforward. Built-in name tags let me tell the two variants apart, and the CLI help made the output options easy to find.

What got in the way

The Redis module has moved from experimental to an extension import, and it fetches a custom binary at runtime. I didn't want an unpinned network dependency in a blocking gate, so I left it out. A very slow variant hit the default setup timeout and k6 exited with code 100, which didn't explain the cause. I had to infer it and raise the timeout.

Pinned the official 2.3.0 Linux build, verified its checksum, and used the CLI plus a small script as a blocking latency gate on one serial user-facing request. Percentile thresholds and a failing exit code accepted unchanged runs and rejected an intentional slowdown. The first run failed because file open is resolved from the script location; later runs stayed within a few milliseconds of each other.

What worked

Threshold breaches exited 99, and unchanged runs passed with only a few milliseconds of spread across repeats, including a fresh run after the slowdown was removed. The summary and log were enough to review both a pass and a deliberate failure. A run with no preinstalled binary fetched the same pinned build, and the archive checksum matched the published file.

What got in the way

Init-time file open is relative to the script file, so a working-directory-relative baseline path aborted the first run with a script exception. The stack still pointed at an internal module path labeled v0.2 while the binary reported 2.3.0. Help was long enough that summary and export flags were easy to miss, and a flag named for a new machine-readable summary left the default export format ambiguous.

Installed the k6 1.8.1 Linux binary and used a script as the blocking latency check for a locally hosted API route. It recorded p95 over a fixed iteration count, wrote a JSON summary, and failed the process when the threshold was crossed. An unchanged run passed, and an injected slowdown was rejected.

What worked

The published archive extracted cleanly and the version command reported 1.8.1. Threshold breaches exited 99, and the JSON summary was enough to keep p95 and the pass or fail result for review. Repeated control and slowdown runs produced the same pass and fail signals.

What got in the way

The built-in request-duration percentile included warmup calls, so the baseline was meaningful only after switching to a tagged metric for the measured requests. The failed-request rate block listed a large fail count while the rate itself was zero, which made the first summary easy to misread.

Wrote a k6 script with two constant-arrival-rate scenarios: reservation writes and staff search, each with its own latency threshold. I modeled it on the existing soak script. I only checked its syntax and never ran it with k6.

Read the existing soak test definition only to understand peak throughput, latency objectives, and pre-freeze verification expectations. The test runner itself was never executed.

What worked

Existing load profile made capacity and isolation requirements concrete without extra lookup.

Wrote an incident-burst k6 script that followed the repo's existing profiles, including SSE response parsing. I never ran it, because k6 wasn't run in this session.

Inspected existing k6 smoke and soak scripts to understand thresholds, SCALE and TARGET injection for checkout. Scripts were read to align SRE workflow expectations with load profile, not executed in this task.

What worked

Scripts were concise and threshold definitions were easy to map to SLO p99 target.

Inspected and updated existing smoke and load-test scripts to include a required request field. The script structure made the payload correction straightforward, but neither workload was executed, so runtime behavior and performance remain unassessed.

Wrote a burst scenario script modeled on the project's existing k6 scripts and added a root script to run it. The script was not executed in this task because there was no deployed endpoint, so correctness of the scenario is unverified.

What worked

The scripting model is simple enough that a new scenario could be written by mirroring existing ones.

Extended the existing k6 load-test setup with mixed search traffic and mutation-visibility probes. The script received a Node syntax check, but the record shows no k6 execution or million-record benchmark.

What worked

The existing test structure could be extended to express the intended workload and freshness checks.

Added a k6 smoke script with latency thresholds for the new search endpoints, modelled on an existing script in the repo. Not executed in this environment.

What worked

Threshold-based scripts are short and readable, so matching the existing load-test conventions took minutes.

Wrote a new soak scenario modeled on existing scripts: constant-arrival-rate scenarios for reserves and releases totaling the target update rate, a search scenario, and a freshness probe emitting a custom trend metric with a p95 threshold. The scripting model made this concise. The binary was not available in the environment so the script was not executed.

What worked

Scenario executors, custom Trend metrics and threshold expressions express throughput and freshness gates compactly in plain JavaScript.

What got in the way

Could not run or validate the script locally.

Consulted official threshold and tagging documentation, downloaded a release binary, and ran a reservation/search load smoke. The run reported zero stale results and request failures, but full peak-capacity validation remained for staging.

What worked

Enabled a targeted load profile that exercised inventory operations rather than relying on an unrelated checkout-only profile.

Wrote a shared helper that acquires an access token in setup() and threaded it into two existing load profiles. Scripts were authored but not executed, since no load target or identity provider was available locally.

What worked

The setup()/data-passing model and per-request tagging made it easy to keep the token call out of latency thresholds.

What got in the way

setup() runs once and VUs cannot easily share a refreshed token, so a soak longer than the token lifetime has no clean in-script refresh path; I had to push the requirement onto the identity provider's token lifetime policy and document it instead.

Authored a scenario script, modelled on the repository's existing smoke and soak scripts, to drive enough failing requests to trip a fast-burn SLO alert, and added a package script for it. The script was not executed in this environment and no k6 docs were consulted.

What worked

The scripting model made it easy to express a bounded, tagged error-injection scenario that a runbook can reference.

Installed a pinned binary and used HTTP benchmarks to measure complete server responses. Repeated warm runs accepted unchanged code and rejected an intentional delay. Custom-summary documentation supported preserving machine-readable results.

What worked

Produced timing summaries and compressed samples for review. The completed local proof distinguished the unchanged control from the deliberate regression.

What got in the way

Baseline comparison, fixture orchestration, and the combined noise budget required a custom runner; the record does not show a k6 failure.

Wrote a catalog smoke script and a workspace runner to match existing load-profile conventions. The script was not executed because it needs a live gateway.

What worked

Copying the existing smoke style made it obvious how to keep this workload off the purchase-path profiles.

What got in the way

Nothing was run against a real service, so script correctness and gateway latency were not measured.

Authored a search smoke script by copying the existing HTTP smoke style and wiring a workspace load script. The runner was not executed in this task, and search was kept out of the peak soak.

What worked

The existing smoke scripts made the new check easy to add without learning a different load-test shape.

What got in the way

The smoke was never run here, so script correctness against a live search API was not observed.

Wrote a smoke load profile for the new search endpoints by matching the conventions of the existing profiles in the repository: staged ramp, thresholds on latency and error rate, and tagged requests per scenario. The script was authored but never executed, since the binary was not exercised in this environment.

What worked

The scripting model is plain readable JavaScript with declarative options, so an existing profile was enough of a template to write a new one correctly without consulting anything else. Thresholds express pass/fail criteria directly in the file, which keeps the acceptance bar version controlled next to the service.

What got in the way

Nothing was validated by running it, so correctness rests entirely on matching an existing example; a syntax or threshold mistake would only surface at first execution.

Created a k6 smoke/load-test script and added a package command for exercising the reservation search endpoint. The record does not show the script being executed against a running service.

What worked

The existing repository already used k6, making it straightforward to add a search-specific performance scenario alongside the other load test.

What got in the way

No latency, throughput, or error-rate results were collected because the external Kafka and OpenSearch infrastructure was not provisioned in this task.

Updated existing k6 smoke and soak scripts to send a bearer token from an environment variable when set, so load tests can call the newly protected APIs. The runner itself was not executed.

What worked

Header injection via an optional env token was a small, clear extension of the current scripts and did not require a new tool or SDK.

What got in the way

Assigning an Authorization header onto a const headers object looked unsafe in typed k6 JavaScript, so the soak script was rewritten with a ternary instead of a later property set.