test: expand flows graph runtime coverage - #54
Conversation
Co-authored-by: Medulla <medulla@tinyhumans.ai>
|
Warning Review limit reached
Next review available in: 18 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
tinysweeper found nothing blocking. Approving.
$0.1022 · 165,468 in / 42,566 out · 15,872 cached (10%) · openrouter/openai/text-embedding-3-small, deepseek/deepseek-v4-pro-0813 · 692 embedded
critique: $0.0508 · 72,667 in / 25,342 out · 6,656 cached (9%) · deepseek/deepseek-v4-pro-0813
security: $0.0316 · 65,679 in / 6,091 out · 5,376 cached (8%) · deepseek/deepseek-v4-pro-0813
tests: $0.0099 · 17,251 in / 3,692 out · 1,920 cached (11%) · deepseek/deepseek-v4-pro-0813
description: $0.0099 · 9,871 in / 7,441 out · 1,920 cached (19%) · deepseek/deepseek-v4-pro-0813
| .await | ||
| .unwrap(); | ||
| assert!(history.len() >= 3, "pause and resumed steps are durable"); | ||
| assert_eq!(history[0].values, completed.state); |
There was a problem hiding this comment.
Compare the latest history entry, not the first
get_state_history most likely returns snapshots in chronological order (oldest first). The assertion compares history[0] — the earliest snapshot — against completed.state, which is the final state after resume. This would fail unless the implementation returns newest first, which is unconventional and not indicated by the call. Use history.last().unwrap().values or explicitly assert the expected earliest state (e.g. State::default()).
[RULE] incorrect-history-assertion ·
How this change flows1 changed behaviour across 22 relationships. 6 surrounding behaviours are shown (60 graph nodes walked). 40 further behaviours left out to keep the diagram readable. flowchart LR
n0["compile_succeeds_for_valid_graph<br/>changed"]:::changed
n1["set_entry"]:::impacted
n2["add_node"]:::impacted
n3["set_finish"]:::impacted
n4["...es_parallel_send_fanout_deterministically"]:::impacted
n5["add_edge"]:::impacted
n6["...aiting_join_and_conditional_route_compose"]:::impacted
n0 -->|calls| n1
n0 -->|tests| n1
n0 -->|calls| n2
n0 -->|tests| n2
n0 -->|calls| n3
n0 -->|tests| n3
n0 -->|calls| n5
n0 -->|tests| n5
n1 -->|calls| n5
n3 -->|calls| n5
n4 -->|calls| n1
n4 -->|tests| n1
n4 -->|calls| n2
n4 -->|tests| n2
n4 -->|calls| n3
n4 -->|tests| n3
n6 -->|calls| n1
n6 -->|tests| n1
n6 -->|calls| n2
n6 -->|tests| n2
n6 -->|calls| n3
n6 -->|tests| n3
classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff
Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge. |
# Conflicts: # tests/fuzz_interception.proptest-regressions
There was a problem hiding this comment.
tinysweeper found nothing blocking. Approving.
$0.0300 · 50,711 in / 10,797 out · 3,328 cached (7%) · openrouter/openai/text-embedding-3-small, deepseek/deepseek-v4-pro-0813 · 676 embedded
critique: $0.0053 · 11,035 in / 974 out · 896 cached (8%) · deepseek/deepseek-v4-pro-0813
security: $0.0052 · 11,014 in / 942 out · 896 cached (8%) · deepseek/deepseek-v4-pro-0813
tests: $0.0117 · 18,343 in / 4,671 out · 768 cached (4%) · deepseek/deepseek-v4-pro-0813
description: $0.0078 · 10,319 in / 4,210 out · 768 cached (7%) · deepseek/deepseek-v4-pro-0813
| .await | ||
| .unwrap(); | ||
| assert!(history.len() >= 3, "pause and resumed steps are durable"); | ||
| assert_eq!(history[0].values, completed.state); |
There was a problem hiding this comment.
Compare the latest history entry, not the first
The test intends to verify that the final resumed state is durable in history, but get_state_history returns entries oldest-first. Indexing [0] compares the initial state to completed.state, which either fails for the wrong reason or passes without proving the resumed state was checkpointed. Compare the latest entry instead, e.g. history.last().expect("history is nonempty").values.
| assert_eq!(history[0].values, completed.state); | |
| assert_eq!(history.last().expect("history is nonempty").values, completed.state); |
[RULE] incorrect-assertion ·
Summary
Validation