Worker Plugins

Worker plugins let you add your own runtime-side reporting or table output. Use them when the built-in plugin data is not enough for your workflow.

What this page helps you do

What this page helps you do

Worker plugins let you add your own runtime-side reporting or table output. Use them when the built-in plugin data is not enough for your workflow.

Who this is for

Teams reading run output or deciding how local reports and exported results should be consumed.

Prerequisites

  • A completed run or a report format you want to enable

By the end

A clearer way to read, choose, or extend the report surface for the workload.

Use this page when

Use this page when you already have run output and need to decide where to start reading or extending the report surface.

Visual guide

Annotated report diagram showing summary, scenario views, and failure analysis.
The same run result powers summary reading, failure diagnosis, grouped correlation, and export flows.

Sample Report Data Rows

Scope    Scenario     Result Count RPS  LatencyP50Ms LatencyP80Ms LatencyP85Ms LatencyP90Ms LatencyP95Ms LatencyP99Ms
Scenario reports-demo OK     675   15.0 21.4         30.2         33.0         36.8         48.6         72.1

LatencyTable Scenario     Result Count LatencyP50Ms LatencyP95Ms
LatencyTable reports-demo OK     675   21.4         48.6
LatencyTable reports-demo FAIL   12    35.9         79.2

StatusCode Result Percent
200        OK     97.48
500        FAIL   2.52

FailedStatus Scope     Scenario     Step StatusCode Count Percent
FailedStatus Scenario  reports-demo      500       12    1.75

Guide

What worker plugins are

Worker plugins let you extend the runtime lifecycle with custom collection or final-report behavior. They are the right place for extra result tables, domain-specific summaries, or custom final artifacts.

What the runtime already includes

LoadStrike automatically registers the built-in failed-response and correlation report worker plugins. You do not need to add those yourself.

How the lifecycle works

Custom plugins receive Init, Start, GetData, Stop, and Dispose phases through the typed service-layer contracts. Init is the place for configuration binding, Start is for run metadata, GetData builds the final plugin output, Stop halts background work, and Dispose performs the last cleanup step.

Why GetData comes before shutdown

LoadStrike calls GetData before Stop and Dispose so your plugin can still read the state it collected during the run. After that, Stop and Dispose can safely release background workers, sockets, timers, writers, or cached clients.

Dispose failure behavior

Dispose is best-effort cleanup. If it throws, LoadStrike logs or records the error and continues the rest of the shutdown path so the finished run result and report artifacts are still produced.

Report and output samples

Use these samples to connect the reporting surface on this page back to the run result your team will review or export.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

HTML reports also include the top-right Light/Dark theme toggle. Light is the default report theme.

Worker Plugin

using LoadStrike;

public sealed class SimplePlugin : ILoadStrikeWorkerPlugin
{
    private string? _lastSessionId;

    public string PluginName => "simple";

    public Task Init(LoadStrikeBaseContext context, Microsoft.Extensions.Configuration.IConfiguration infraConfig) => Task.CompletedTask;

    public Task Start(LoadStrikeSessionStartInfo sessionInfo)
    {
        _lastSessionId = string.Join(",", sessionInfo.Scenarios.Select(x => x.ScenarioName));
        return Task.CompletedTask;
    }

    public Task<LoadStrikePluginData> GetData(LoadStrikeRunResult result)
    {
        var table = LoadStrikePluginDataTable.Create("summary");
        table.Rows.Add(new Dictionary<string, object> { ["name"] = "requests", ["value"] = result.AllRequestCount });

        var data = LoadStrikePluginData.Create(PluginName);
        data.Hints.Add("Adds a custom report table.");
        data.Tables.Add(table);
        return Task.FromResult(data);
    }

    public Task Stop() => Task.CompletedTask;

    public Task Dispose()
    {
        _lastSessionId = null;
        return Task.CompletedTask;
    }
}

var plugin = new SimplePlugin();
var scenario = LoadStrikeScenario.Empty("plugin-demo")
    .WithLoadSimulations(LoadStrikeSimulation.KeepConstant(1, TimeSpan.FromSeconds(20)));

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithWorkerPlugins(plugin)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Worker plugin contract and methods

PluginName

Required stable plugin identifier used in licensing checks and output tables.

Built-in auto registration

LoadStrike adds the built-in failed-response and correlation plugins automatically when those result surfaces have data. Do not register those built-in plugin names manually.

Init(context, infraConfig)

Initializes the plugin with typed runtime metadata and infra-config access.

Start(sessionInfo)

Called when the run session starts and session metadata becomes available.

GetData(result)

Builds the final plugin output from the base LoadStrikeRunResult before reports are written and before plugin tables are merged back into the final artifact.

Stop()

Called after GetData so the plugin can stop background work cleanly.

Dispose()

Final best-effort cleanup phase for releasing resources such as timers, writers, or client objects.

LoadStrikeRunResult.pluginsData / PluginsData

The final result artifact keeps every plugin row with its hints and tables, and those same tables feed the HTML plugin tabs plus final sink export.

LoadStrikePluginData / LoadStrikePluginDataTable

Typed output helpers used for plugin sections and tables in the final report.