← Back to project catalogue
GP-CS-07ZZ37HComputer ScienceReady

Go event workflow replay and fault debugger

A Go engineering laboratory that records event histories, injects controlled delivery faults, and compares naive and protected workflow replay.

Go event workflow replay and fault debugger project visual
GP-CS-07ZZ37H · Computer Science
  • Go 1.27
  • NATS Server 2.14.5
  • nats.go 1.53.1
  • CloudEvents 1.0
  • Python

Project definition

Problem statement

An event-driven workflow can produce an incorrect result even when every component appears healthy. Duplicate delivery, lost messages, delayed events, reordering, and a crash before acknowledgement can change state or repeat an external effect.

The engineering problem is to retain enough evidence to replay the delivery history, compare expected and observed findings, and demonstrate which protections prevent an incorrect outcome.

Project objectives

  • Define and validate a CloudEvents-compatible workflow envelope with identity, causation, correlation, sequence, and trace context.
  • Apply duplicate, drop, delay, swap, redelivery, crash-before-acknowledgement, and broken-causation faults without changing the source events.
  • Compare a naive replay with a protected replay that uses event identities, effect identities, ordering, causal checks, and workflow invariants.
  • Run the same labelled corpus through memory and embedded NATS JetStream transports.
  • Measure exact finding agreement, deterministic repetition, recovery, and protected replay scaling.

Project structure

Project components

01

Scenario loader

Loads bounded local JSON or YAML scenarios, rejects unknown fields and symlinks, and validates every event before execution.

02

Fault engine

Creates repeatable delivery histories for duplicates, drops, delays, swaps, redelivery, acknowledgement loss, and causation faults.

03

Transport layer

Runs the prepared delivery history directly in memory or through an embedded NATS JetStream server with explicit acknowledgement.

04

Replay modes

Compares an intentionally naive consumer with a protected consumer using deduplication, effect keys, ordering, causality, and invariants.

05

Evidence writers

Stores the journal and exports findings, state, effects, hashes, timing, and limitations to reviewable formats.

06

Experiment runner

Evaluates all 12 scenarios in both modes and performs 11 scaling trials at four event counts.

Methodology

Project workflow

  1. 01
    Choose a scenario

    The student selects a labelled order workflow and reviews its events, fault plan, and expected findings.

  2. 02
    Build the delivery journal

    The declared fault is applied to a copy of the source events and the resulting delivery order is retained as JSONL.

  3. 03
    Run both replay modes

    The same journal is processed by the naive and protected consumers.

  4. 04
    Check the result

    Observed findings, final state, effects, recovery, and deterministic hashes are compared with the scenario declaration.

  5. 05
    Export evidence

    The command writes JSON, CSV, Markdown, escaped HTML, and combined dashboard evidence.

Demonstration scenario

A synthetic order reaches shipment scheduling, but the consumer crashes before acknowledging that event. JetStream redelivers it. The naive replay records a duplicate shipment effect and a sequence regression. The protected replay recognises the repeated event identity, suppresses the duplicate effect, and recovers the workflow. Both runs retain the same six-delivery journal for comparison.

Engineering

Tools and method

Go core
Standard Go packages separate the event model, scenario loading, fault transformation, replay, evaluation, scaling, and evidence boundaries.
Broker experiment
NATS Server runs in process with JetStream memory storage so the broker path is real but remains local and repeatable.
Event contract
The model validates CloudEvents-compatible identity and time fields plus workflow sequence, causation, correlation, and W3C traceparent syntax.
Protected replay
Event ID and effect-key deduplication, per-subject ordering, causal checks, and domain invariants prevent or expose prepared faults.
Output safety
Bounded inputs, regular-file checks, symlink rejection, parent creation, HTML escaping, and explicit output paths protect the local experiment boundary.
Documentation tools
Python rebuilds the figures, dashboard, Word documents, PDFs, page map, and repository checks from retained evidence.

Testing

Evaluation

Evaluation measures

  • 24 of 24 exact expected finding matches with memory transport
  • 24 of 24 exact expected finding matches with embedded JetStream transport
  • 24 of 24 deterministic repeats for each transport
  • 9 protected recoveries compared with 2 naive recoveries
  • 11 repeated scaling trials at 50, 500, 2,500, and 5,000 events
  • 58 passing Go test and subtest events plus race, static, dependency, repository, document, and accessibility checks

Project boundaries

  • The laboratory uses synthetic orders and never connects to payment, inventory, shipping, customer, or university systems.
  • The JetStream mode is an embedded single-node memory experiment, not a production cluster benchmark.
  • The retained accuracy and recovery results apply only to the 12 prepared scenarios.
  • The project demonstrates selected replay protections and does not promise exactly-once delivery or certify a production system.

Included

  1. 01Go command-line replay laboratory and reusable packages
  2. 02Twelve labelled baseline, duplicate, missing, delayed, reordered, redelivery, causation, and compensation scenarios
  3. 03Memory and embedded NATS JetStream experiment modes
  4. 04JSON, CSV, Markdown, HTML, and dashboard evidence
  5. 05Retained evaluation and repeated scaling results
  6. 06Complete source code in a private GitHub repository
  7. 07Complete 118-page project documentation in PDF and editable Word formats
  8. 08Complete 15-page setup and usage guide in PDF and editable Word formats

Project record

No information is collected on this page.

Permanent project ID
GP-CS-07ZZ37H
Catalogued
21 Aug 2026
Completed
24 Aug 2026
Verified
24 Aug 2026
Demonstration
Included in repository

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.