var_load

The var_load transform reads a named variable from the session's variable cache and emits its value as the chain's token. It is the read half of the var_store / var_load pair that moves values from one RRPair into another within the same replay session.

It does not match by value or scan the RRPair — it pulls a single named entry from the cache and writes it through the chain's extractor.

• Transform type name (config/API): var_load
• Shorthand format: var_load(name=...)

Quick Start

Load a value previously captured by var_store:

"type": "var_load",
"config": {
    "name": "access_token"
}

This transform is most often the last step in a chain that writes the loaded value into a request field — for example, an Authorization header.

How It Works

var_load is structured so the load happens on the write back, not when the upstream extractor produces a value.

1. First phase — the extracted token is passed through unchanged. Other transforms downstream in the chain are not given the loaded value at this stage; this lets var_load participate in single-transform chains without disturbing chain semantics.
2. Second phase — read the variable named name from the variable cache and emit its bytes. The extractor then writes that value back into the targeted field of the RRPair.

If the variable is not present in the cache, the second phase emits an empty byte slice. The target field is rewritten to an empty value rather than left alone. This is the most common source of "my header is suddenly empty" surprises — see Troubleshooting.

Variable Cache Scope

The cache is shared by every chain that runs in the same replay session. Anything stored by an earlier RRPair's var_store chain is available to later RRPair's var_load chains, including across services, until the session ends.

A var_store and a matching var_load do not need to live in the same chain. The expected pattern is:

RRPair A (e.g. /login):  res_body() → json_path(path="access_token") → var_store(name=access_token)
RRPair B (e.g. /orders): http_req_header(header="Authorization") → var_load(name=access_token)

The Speedscale analyzer's tuner treats var_store / var_load pairs that share a name as logically grouped — moving them between RRPairs in the same session is supported.

Configuration

"type": "var_load",
"config": {
    "name": "<string>"
}

Parameter	Required	Default	Description
name	Yes	—	The variable cache key whose value will replace the field's contents. Missing name fails chain initialization.

Examples

Example 1 — Replay an auth token captured from /login

http_req_header(header="Authorization") → var_load(name=access_token)

If access_token=Bearer eyJhbGciOi... was stored by an earlier RRPair, the Authorization header on this RRPair is rewritten to that value.

Example 2 — Inject a value into a JSON body field

req_body() → json_path(path="userId") → var_load(name=current_user_id)

Rewrites the userId field of the request body to whatever is currently held under current_user_id in the variable cache.

Example 3 — Pair with var_store

RRPair A response: res_body() → json_path(path="id") → var_store(name=order_id)
RRPair B request:  http_url(subdirIndex=1) → var_load(name=order_id)

The id from the first response is substituted into the URL subdirectory of the next request. This is the canonical pattern for chaining REST resources whose IDs are generated by the server.

Common Misconceptions

1. "It reads the variable during the first phase." No. The first phase passes the upstream value through unchanged. The actual read happens in the second phase, just before the value is written back into the targeted field.

2. "A missing variable leaves the field alone." No. A missing variable causes the second phase to emit an empty byte slice, and the field is rewritten to empty. If you need a fallback, set the variable beforehand (e.g. with an earlier chain) or use constant instead.

3. "var_load and var_store must live in the same chain." No. They communicate through the cache, which spans the entire session. The canonical use is var_store on one RRPair and var_load on a later one.

4. "The ${{var:name}} syntax does the same thing." They overlap but are not identical. ${{var:name}} is in-string substitution inside another transform's value (e.g. inside constant). var_load is a standalone chain step that owns the full token. Use var_load when the entire field's value comes from the variable; use ${{var:name}} when the variable is one piece of a larger templated string.

Troubleshooting

Symptom	Likely cause	Fix
Chain init: missing variable name (key=name)	name is not set in the config	Add name: <variable>
Target field is empty after the transform	Variable does not exist in the cache yet	Make sure an earlier RRPair runs a var_store chain for the same name, or seed the variable through another mechanism
Value is stale (not the freshest stored value)	An earlier transform in the chain overrode the loaded token	var_load writes during the second phase; check that no later transform in the chain replaces the value
Authorization header includes " quotes	The stored value was a JSON-quoted string (e.g. captured from a JSON scalar)	Pair var_store with a trim or regex to strip quotes before storing
Loaded value not visible in another service's replay	Replay was restarted between the store and the load, or the two services don't share the same replay session	Run them as a single multi-service replay so they share the variable cache

Related Transforms

• var_store — the write half of this pair. Captures the chain's current token into a named variable.
• constant — supports ${{var:name}} for in-string variable substitution; use when the variable is part of a larger templated value.
• smart_replace — alternative pattern for value propagation that matches by value across the RRPair, without explicit names.

For an end-to-end walkthrough of capturing a token from one service and injecting it into another, see Multi-service replay and the Variables guide.

Advanced Notes

• The session-scoped variable cache persists for the duration of the replay or mock-server run. A value stored early in the session remains available to every later RRPair, regardless of which chain stored it.
• The transform reports no required Kubernetes secrets — name is the only configuration it consumes.
• var_load does not require the recorded response to be present in the action file; it only consults the in-memory cache.
• Concurrent RRPair processing through the same chain shares the cache. Reads are safe; if your replay pattern relies on a precise store-then-load ordering, sequence the relevant RRPairs accordingly.