Lifecycle functionality (Fallback SDK)

Our SDKs allow indicating when certain milestones in program setup and execution have been reached. If you cannot use the SDK, you can still indicate these milestones by writing JSONL messages to $ANTITHESIS_OUTPUT_DIR/sdk.jsonl.

You must emit JSONL messages. Each individual message must be a single line of JSON that terminates in a newline character. However, the examples show JSON messages spread across multiple lines purely for readability. This will not work in practice. Each message must be a single line.

Setup

Setup indicates to Antithesis that your system and workload are fully initialized.

To use this functionality, have your program emit the following JSONL once startup is complete:

{"antithesis_setup": { "status": "complete", "details": null }}

The item details may be any JSON that you wish to log at startup time. If you do not want to record additional information, it may be set to null as above. Note that details must not terminate with a newline, because the entire message must ultimately be JSONL.

The following setup example logs additional information by setting details:

{"antithesis_setup": { "status": "complete", "details": {"workload-size": 37, "initiated_by": "John Doe" }}}

Event

Event indicates to Antithesis that a certain event has been reached. It provides greater information about the ordering of events during the course of testing in Antithesis. It is a JSONL message consisting of:

  • a single top-level field that is the event’s name, which points to
  • Arbitrary JSON that contains any details you want to log. Note that these details must not contain any newlines except for the newline that terminates the message. The entire message must ultimately be JSONL.

To use this functionality, have your program emit a JSONL message when the event is reached. Your message should look similar to the following (but without newlines, which are only for readability):

{
    "your_event_name": {
        "node_status": "up",
        "nodes_up": ["worker 1", "worker 2", "worker 3"]
    }
}
  • Introduction
  • How Antithesis Works
  • Getting started
  • Package your software
  • Make it go
  • Deploy to Antithesis
  • Launch a test run
  • User manual
  • Properties and Assertions
  • Properties in Antithesis
  • Assertions in Antithesis
  • Properties to Test For
  • Sometimes Assertions
  • Test Composer
  • Test Composer Basics
  • Test Composer Reference
  • Principles of Test Composition
  • Checking Test Templates Locally
  • Webhooks
  • Launching a test
  • Retrieving logs
  • Launching a debugging session
  • Webhook API
  • Reports
  • Triage report
  • Bug report
  • Multiverse debugging
  • Overview
  • Exploring the multiverse
  • Querying with event sets
  • The Environment and its utilities
  • Using the Antithesis Notebook
  • Cookbook
  • The Environment and Multiverse
  • The Antithesis Environment
  • Fault Injection
  • CPUID
  • Reference
  • Handling External Dependencies
  • SDK reference
  • Go
  • Tutorial
  • Instrumentor
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Java
  • Tutorial
  • Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • C
  • C++
  • Tutorial
  • C/C++ Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • JavaScript
  • Python
  • Tutorial
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • Rust
  • Tutorial
  • Instrumentation
  • Assert (reference)
  • Lifecycle (reference)
  • Random (reference)
  • .NET
  • Languages not listed above
  • Assert (reference)
  • Lifecycle (reference)
  • Tooling integrations
  • CI integration
  • Discord and Slack integrations
  • Configuring Antithesis
  • Instrumentation
  • User management
  • Sizing your deployment
  • Best practices
  • Is Antithesis working?
  • Optimizing for Antithesis
  • Finding more bugs
  • Release notes
  • Release notes