Introduce lading_antithesis - #1920
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
I am gearing up to add Antithesis rig to this project, my rough goal being to eventually absorb and then expand on the existing integration test mechanism. There will be a couple of 'ducks' and 'sheepdog' in the project up-stack from this, I imagine. This new crate wraps the Antithesis Rust SDK and gives SUT assertions a more tidy appearance. This is ported from my work on Datadog/saluki.
6108c98 to
128b02f
Compare
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 128b02ff5d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| lading: | ||
| build: | ||
| context: /home/ssm-user/src/lading | ||
| dockerfile: test/antithesis/scenarios/general/Dockerfile |
There was a problem hiding this comment.
At this commit, a repo-wide search finds no test/antithesis/scenarios/general/Dockerfile; the only occurrence of this path is in this compose file. Consequently, all three services reference a nonexistent build file and the new Antithesis scenario cannot be built or launched. Commit the Dockerfile with the lading, sink, and workload stages, or point these services at an existing build file.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Ah this is pollution from up-stack. This branch should only have lading_antithesis in it.
| updated: 2026-07-24T21:28:13Z | ||
| external_references: | ||
| - name: the deployment (production runner-orchestrator, generic name) | ||
| why: real shutdown/deploy model — RJO launches lading as an ECR container in a |
There was a problem hiding this comment.
This em dash is representative of non-ASCII punctuation introduced throughout most of the new scratchbook documents, including arrows, section symbols, and comparison glyphs. Repository documentation is explicitly restricted to US-ASCII, so these additions should replace those characters with ASCII equivalents.
AGENTS.md reference: AGENTS.md:L137-L137
Useful? React with 👍 / 👎.
| Both lading's SUT bootstrap (`lading/src/antithesis_hooks.rs`) and the Antithesis | ||
| workload drivers under `antithesis/` reach the SDK through this crate, never | ||
| `antithesis_sdk` directly, so an assertion reads identically wherever it lives. |
There was a problem hiding this comment.
A repo-wide search for antithesis_hooks, lading_antithesis, and SDK assertion usages finds no lading/src/antithesis_hooks.rs, no workload drivers, and no consumer of this facade outside its own crate and workspace metadata. This present-tense claim therefore documents an integration that does not exist in this commit; either add those consumers or describe them as planned usage so readers do not assume the SUT is already instrumented.
Useful? React with 👍 / 👎.
| workspace = true | ||
|
|
||
| [dependencies] | ||
| lading-antithesis = { workspace = true, features = ["antithesis"] } |
There was a problem hiding this comment.
Following this manifest example fails because the root [workspace.dependencies] contains antithesis_sdk but no lading-antithesis entry; being a workspace member alone does not make a crate available through { workspace = true }. Add a path dependency such as lading-antithesis = { path = "lading_antithesis" } to the root workspace dependencies, or make this planned consumer use an explicit path.
Useful? React with 👍 / 👎.
| mod enabled { | ||
| /// Asserts `condition` holds every time this line runs, and that the line runs at least once. | ||
| #[macro_export] | ||
| macro_rules! always { |
There was a problem hiding this comment.
The enabled and disabled modules manually repeat the same two-arity facade shape for fifteen exported macros, so adding or changing an assertion requires synchronized edits across a large duplicated surface and can easily leave feature modes inconsistent. Introduce a helper macro that generates these wrappers, with parameters for the forwarded SDK macro and documentation, instead of maintaining each shape separately.
AGENTS.md reference: AGENTS.md:L95-L95
Useful? React with 👍 / 👎.
| .context("parse RECEIVER_LISTEN_ADDR")?; | ||
| let mode_path: PathBuf = std::env::var_os("RECEIVER_MODE_PATH") | ||
| .map_or_else(|| PathBuf::from(DEFAULT_MODE_PATH), PathBuf::from); | ||
| let mode = Mode::from_file(&mode_path); |
There was a problem hiding this comment.
Under the ordering prescribed later in this plan, the workload depends on the receiver becoming healthy, so the receiver performs this one-time read before the workload can write receiver_mode; the missing file becomes Mode::Ok, is stored for the process lifetime, and the later write at Task 6 is never observed. Every planned retryable, stall, reset, and garbage_ok timeline therefore silently runs in benign mode. Wait for the mode/ready sentinel before reading it, start the workload first, or reload the file after it appears.
Useful? React with 👍 / 👎.
1 participant
What does this PR do?
This new crate wraps the Antithesis Rust SDK and gives SUT assertions a
more tidy appearance. This is ported from my work on Datadog/saluki.
Motivation
I am gearing up to add Antithesis rig to this project, my rough goal
being to eventually absorb and then expand on the existing integration
test mechanism. There will be a couple of 'ducks' and 'sheepdog' in the
project up-stack from this, I imagine.
Related issues
n/a