extending-personhog-test-harness

Adds chaos scenarios, stack disruptions, and invariants to the personhog e2e test harness.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill extending-personhog-test-harness
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: extending-personhog-test-harness
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/extending-personhog-test-harness
Command: npx skills add https://github.com/PostHog/posthog-foss --skill extending-personhog-test-harness

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Fixing a bug in the personhog leader path (leader, router, writer, replica, coordination protocol) without a permanent regression test leaves the door open for the same failure to return. This Skill guides you through adding chaos scenarios, new failure modes, and correctness invariants to the personhog e2e test harness so every fix becomes a reproducible, CI-enforced regression test.

Core Features & Use Cases

  • Chaos scenario authoring: Add new disruptions (SIGKILL crashes, SIGTERM drains, SIGSTOP/SIGCONT zombies, writer lag, coordinator kills, etcd lease revocations) via GateArgs flags, ChaosEvent variants, and chaos_timeline entries.
  • Invariant extension: Add new correctness properties to the acked-write journal in state.rs, with unit-tested decision tables so verifiers cannot silently false-negative.
  • Fix validation workflow: Run the harness against fix-branch binaries to show a scenario red on the base branch and green on the fix, then wire rehearsed scenarios into the personhog-gate CI job.
  • Use Case: After fixing an eviction data-loss bug in the personhog leader, add a chaos scenario that reproduces the eviction mid-write, verify it fails on the base branch and passes on your fix, and register it in ci-rust.yml as a permanent regression gate.

Quick Start

Ask the assistant to add a chaos scenario to the personhog test harness that reproduces the leader-path bug you just fixed and validate it against your fix branch binaries.

Frequently Asked Questions about extending-personhog-test-harness

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a chaos scenario to the personhog test harness?

Add a GateArgs flag in cli.rs, a ChaosEvent variant and chaos_timeline entry in gate.rs, and any new stack primitive in stack/mod.rs. Guard invalid flag combinations with an early bail, rehearse until three consecutive green runs, then add it to the personhog-gate CI job.

How do I validate a personhog bug fix with the test harness?

Build the personhog binaries from your fix branch, then run personhog-test-harness gate with your scenario flags and --bin-dir pointing at the fix build. Show the same command red on the base branch and green on the fix in the PR's testing section.

When should I add a new scenario versus reuse existing flags?

Add a scenario when fixing a bug whose trigger the harness can reproduce, or when introducing a new failure mode or correctness property. Do not add one for behavior already covered by an existing flag combination; compose existing flags instead.

Why does a new harness invariant need unit tests in state.rs?

A false-negative verifier looks identical to a healthy stack, so end-to-end runs cannot reveal it. New invariants go in the acked-write journal in state.rs with unit-tested decision tables to prove the verifier actually detects violations.

What should I do with a scenario that stays red due to a known defect?

Document it in the harness README's Known defects section with its observable signature and fix direction. Keep expected-red scenarios out of the personhog-gate CI job until the underlying defect is fixed.