octoperf-auto-correlation

OctoPerf — Auto-correlation workflow

When a recorded Virtual User (VU) fails its replay because dynamic server-issued values become stale, correlation is the fix: extract the new value from a response and inject it into the next request. This skill drives that loop through the MCP tools without manually editing the VU.

When this applies

Apply this skill in one of two modes.

Reactive — when all of:

• The VU was imported (import_har_virtual_user, upload_jmx_virtual_user, import_postman_virtual_user, …) — not hand-written.
• A validate_virtual_user run finished with failures.
• The failures look like dynamic-value mismatches: HTTP 401/403 on the second+ request, server errors about "invalid token", "expired session", "CSRF mismatch", "signature verification failed", "nonce reused", or response bodies referencing IDs/keys that don't match what the request sent.

Proactive — validation is clean but a run_scenario is planned. A 1-user validation often masks correlation gaps because JMeter's CookieManager auto-handles session cookies — under concurrent load the same VU can break (per-session token binding, race conditions, WAF heuristics). Walk the VU with get_virtual_user and look for hardcoded server-generated values still in place: long base64 / hex strings, session ids in URL paths (;jsessionid=...), hidden form tokens (_sourcePage, __fp, __VIEWSTATE, …), JWTs in headers. Apply step 2 (framework presets) to harden, then re-validate.

If failures are about request bodies (wrong JSON shape), missing variables, HTTP server config (wrong timeout / baseUrl), or 5xx server errors unrelated to identity — this is not an auto-correlation problem; use the validation-triage skill instead.

Steps

0. Snapshot the VU before you rewrite it

Correlation rewrites the VU's action tree in place, and OctoPerf has no VU versioning — apply_correlations_to_virtual_user and a bad custom rule are hard to undo. Take a one-call backup first: