Lifecycle-aware Dance Test Infrastructure for Transaction Semantics (Phase 1.3 Follow-up)

[owleyeview]

1. Summary

What is the enhancement?
Extend the Dance Test Framework to support transaction lifecycle correctness guarantees aligned with Phase 1.3 (Open → Committed), including commit/load lifecycle transitions and negative-path behavior, while preserving backward compatibility for existing fixtures.

---

2. Problem Statement

Why is this needed?

Phase 1.3 introduced explicit transaction lifecycle semantics and host-side commit ingress guarding. However, the current sweetests infrastructure:

• Treats commit and load_holons primarily as status-only operations.
• Does not model or assert lifecycle transitions.
• Assumes success-path behavior in several adders and executors.
• Mutates fixture state unconditionally in some commit-like flows.
• Parses response bodies before validating expected status.
• Allows multiple commit-like operations per transaction in ways that may conflict with strict Open → Committed semantics.

Additionally, most dance tests execute through a TrustChannel DanceInitiator, bypassing host ingress checks in the receptor. While this is acceptable for testing most behavior, it means lifecycle correctness must be modeled explicitly within the harness if we want deterministic guarantees.

Without lifecycle-aware assertions, there is a growing gap between runtime transaction semantics and the guarantees provided by the test framework.

---

3. Dependencies

Does this depend on other issues or features?

• Depends on Phase 1.3 transaction lifecycle semantics being stable.
• May interact with future transaction-selection or multi-transaction support.
• Does not require host-ingress execution mode migration.
• Does not require changes to production lifecycle APIs.

---

4. Proposed Solution

How would you solve it?

Introduce lifecycle-awareness into the Dance Test Framework in a minimal and backward-compatible way.

At a high level:

1. Allow commit-like steps (commit, load_holons) to declare lifecycle expectations.
2. Ensure lifecycle-driving response properties (e.g., commit/load status) are surfaced and validated.
3. Prevent fixture state mutation on expected-failure paths.
4. Remove unconditional success assumptions in executors.
5. Enable negative-path lifecycle tests (e.g., mutation rejected after commit).

Lifecycle assertions may be implemented through:

• expectation metadata on commit-like steps,
• a harness-level lifecycle tracker,
• and/or explicit lifecycle assertion steps.

The implementation should:

• Keep existing add_commit_step behavior intact by default.
• Provide opt-in lifecycle-aware variants(eg. add_commit_and_assert_committed(...) or add_commit_step_with_expectations(...)).
• Ensure lifecycle transitions are driven by response properties, not just HTTP-like status.

The goal is correctness and clarity, not architectural perfection in the first pass.

---

5. Scope and Impact

What does this impact?

• dance_test_language.rs (commit/load step definitions and adders)
• Commit and load executors
• Fixture state mutation logic (e.g., fixture head updates)
• Test runner execution state
• Negative-path behavior across multiple executors
• Lifecycle-related fixture cases

It does not require:

• Changes to production transaction lifecycle logic
• Migration of all tests to host-ingress mode
• Immediate refactoring of all multi-commit fixtures

Existing sweetests must continue to compile and pass unchanged unless they explicitly opt into lifecycle assertions.

---

6. Testing Considerations

How will this enhancement be tested?

New dedicated lifecycle fixtures should be added to validate:

• commit with Complete → transaction becomes Committed.
• commit with Incomplete → transaction remains Open.
• load_holons with lifecycle-finalizing status → transaction becomes Committed.
• Failed commit-like operations do not advance fixture state.
• Mutations are rejected once Committed.
• Commit-like operations are rejected once Committed.
• Executors no longer panic on valid non-OK expectations.

Existing sweetests must continue to pass without modification.

Unit tests for host_commit_in_progress remain separate and sufficient for internal host concurrency behavior.

---

7. Definition of Done

When is this enhancement complete?

• Commit and load executors safely handle both success and non-success expectations.
• Fixture state is not mutated on expected failed commit-like operations.
• Lifecycle-driving response properties are surfaced and validated.
• Lifecycle-aware fixtures pass and deterministically assert expected transitions.
• Existing sweetests pass unchanged.
• No executor assumes success-path behavior unconditionally.
• Lifecycle behavior in tests aligns with Phase 1.3 runtime semantics.

---

Optional Details (Expand if needed)

8. Alternatives Considered

What other solutions did you think about?
Briefly describe alternatives and why this approach is preferred.

---

9. Risks or Concerns

What could go wrong?
Highlight potential challenges, like performance or compatibility issues.

---

10. Additional Context

Any supporting material?
Include links, screenshots, logs, or diagrams.

---