Skip to content

test: add canonical append-log example#23

Merged
siphonite merged 1 commit intomainfrom
issue-16-canonical-example
Feb 6, 2026
Merged

test: add canonical append-log example#23
siphonite merged 1 commit intomainfrom
issue-16-canonical-example

Conversation

@siphonite
Copy link
Owner

Summary

Adds the canonical example test to validate the FIRST API is clean and usable.

Changes

  • Create tests/canonical_append_log.rs with:
    • Append-only log workload (2 writes + fsync)
    • 3 explicit crash points
    • Prefix-consistency invariant verification

Verification

  • cargo fmt -- --check
  • cargo clippy -- -D warnings
  • cargo test --test canonical_append_log ✅ (1 test passes)

Closes #16

Validates the FIRST API with a minimal crash-consistency test:
- Append-only log with 2 writes + fsync
- 3 explicit crash points
- Prefix-consistency invariant check

Closes #16
@siphonite siphonite merged commit 166c1bc into main Feb 6, 2026
2 checks passed
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 05a128cfde

ℹ️ 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".

Comment on lines +39 to +46
// INVARIANT: Records are prefix-consistent
// Either: [], ["RECORD1"], or ["RECORD1", "RECORD2"]
// Never: ["RECORD2"] alone (would violate append-only semantics)

match records.as_slice() {
[] => { /* Nothing persisted - fine */ }
["RECORD1"] => { /* Partial - fine */ }
["RECORD1", "RECORD2"] => { /* Complete - fine */ }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Enforce durability after fsync crash point

The invariant currently allows [] or "RECORD1" even when the crash happens at the explicit after_fsync point. At that point fsync() has returned, so the log should be fully durable under FIRST’s model; accepting empty/partial states will let durability regressions (e.g., missing/ignored fsync) pass undetected. Consider using crash_info.label (or point id) to require "RECORD1","RECORD2" when the crash is at after_fsync.

Useful? React with 👍 / 👎.

siphonite added a commit that referenced this pull request Feb 6, 2026
Use crash_info.label to differentiate expected states:
- Before fsync: any prefix is acceptable
- After fsync: both records MUST be present

Addresses review feedback on #23
siphonite added a commit that referenced this pull request Feb 6, 2026
Use crash_info.label to differentiate expected states:
- Before fsync: any prefix is acceptable
- After fsync: both records MUST be present

Addresses review feedback on #23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Minimal Example Test (API Validation)

1 participant