2 world entry smoke harness and soak telemetry
forgejo-actions edited this page 2026-07-13 19:45:35 +00:00

World Entry Smoke Harness And Soak Telemetry

The world-entry smoke harness validates that a built client, content pack, and service stack can enter the world and satisfy required realtime assertions. Soak telemetry turns its reports into longer-running Control Panel trends.

Mode-specific CLI semantics and probe intent live close to src/bin/world_entry_smoke.rs and in the command's --help output. This page is the operator checklist for repeatable runs, artifact retention, and failure triage.

How It Works

Scenario descriptors in xtask/src/smoke_contract.rs define scenario ids, default arguments, required services, report paths, telemetry modes, and expected assertions. The harness connects as a realtime client, runs the selected flow, records required and optional checks, and writes a machine-readable report. Pack-export gates can invoke server-smoke scenarios after content packaging, while Control Panel telemetry reads report history to expose regressions across runs.

List the current descriptor-backed scenarios with:

cargo run --bin world_entry_smoke -- --help

Use those scenario ids when matching smoke artifacts to xtask gates or Control Panel telemetry. Ad hoc repeat, soak, negative, and disconnect probes remain supported by the CLI but are not part of the shared scenario contract unless they appear in --help.

Prerequisites

  • Point .env.local at the development Postgres and Redis services.
  • Start the backend stack in separate terminals:
cargo run -p aether-control-plane
cargo run -p aether-login-server
cargo run -p aether-game-server
  • Decide how the smoke account will exist: create it in Control Panel, use an existing account, or pass --register-if-login-fails. The example below assumes a dev account with password dev.

Run A Scenario

Start with the scenario arguments shown by --help, then supply the login URL and credentials for the stack under test. A basic direct run is:

cargo run --bin world_entry_smoke -- \
  --login-base-url http://127.0.0.1:7000 \
  --username dev \
  --password dev \
  --report-file ./artifacts/world-entry-smoke.json

Useful additions include --register-if-login-fails, --peer-username, repeated --bot-account, --negative-case, --disconnect-case, --reconnect-probe, --repeat-count, and --soak-duration-seconds. Prefer a descriptor-backed scenario for shared gates and dashboards.

For development packet capture, set AETHER_PACKET_DEBUG_CAPTURE_DIR before launching the harness or server process:

$env:AETHER_PACKET_DEBUG_CAPTURE_DIR = ".\artifacts\packet-debug"
cargo run --bin world_entry_smoke -- `
  --login-base-url http://127.0.0.1:7000 `
  --username dev `
  --password dev `
  --register-if-login-fails `
  --report-file .\artifacts\world-entry-smoke.json

Farming Cycle Fixture

world-entry-farming-cycle is descriptor-backed but intentionally excluded from the default server-smoke gate until smoke accounts can reliably load the farming test scene.

Before running it, place the smoke character in scenes/farming_test.scene, field fields.west, layer 1, tile (4, 5), with at least one farming.seed_bag.barley stack. The harness tills, plants crops.barley, waters, waits for a mature farming delta, harvests, and verifies seed consumption plus farming.crop.barley produce grants through inventory snapshots.

Success Criteria

  • The command exits with code 0.
  • The requested report exists and contains "success": true.
  • The staged report reaches the scenario's expected end state without an earlier failed stage.
  • Required assertions represent conditions that make world entry unsafe; optional assertions add context but never hide failure.
  • Soak summaries show more than one completed iteration.
  • For negative or disconnect runs, success means the expected rejection or disconnect occurred cleanly.
  • Keep reports, packet captures, and matching server logs under artifacts/; do not commit them.

Failure Capture And Triage

Keep the smoke terminal output because it names the exact failing stage. Save the JSON report and login/game-server logs from the same run window. Record the stage, reported message, username, realm, and character.

For failures before game handshake, include the HTTP status or request error. For failures after QUIC connect, include the disconnect reason or packet-decode error and nearby game-server log lines. Enable packet capture when messages arrive in the wrong order, violate generated limits, or do not arrive at all.

Common causes are unavailable services, wrong environment values, stale credentials, packet-capture path issues, assertion timeouts, and stale report directories.

Repeatability

  • Use the same username and character when comparing runs.
  • Prefer one smoke attempt at a time while the stack is single-zone or the protocol is changing quickly.
  • Rerun after transport-edge, authentication/handoff, bootstrap, realtime welcome/snapshot, or content-pack changes.
  • Keep reports and logs from the same time window together.
  • Preserve report-schema compatibility for automation and Control Panel consumers.