You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI fix: failing checks on PR #82 (branch technocore/issue-81-fix) #83
CI checks are failing on PR #82 (branch technocore/issue-81-fix), blocking it from review.
Failing checks
Tests via tox (Python 3.12): failure
Task
Fix the CI failures by branching from technocore/issue-81-fix and opening a fix-up PR targeting technocore/issue-81-fix as the base.
Do NOT branch from main — branch from the failing PR's branch so the fix applies on top of the existing work.
Starting work on this issue. I'll investigate the failing tox (Python 3.12) checks on PR #82, branch technocore/issue-81-fix, then open a fix-up PR targeting that branch.
Found it: segfault (exit code -11) in trend_analysis at python/eo_processor/__init__.py:378 during test_trend_analysis_detects_break. Let me examine the code.
The segfault is a stack overflow from infinite recursion in src/trends.rs:73-75. When max_residual_index == 0, y.split_at(0) returns left=[] and right=y (the whole array), so recursive_trend_analysis recurses forever on the same slice. Let me reproduce it.
No Python/Rust toolchain available locally, so I'll simulate the exact Rust algorithm in JS to find the recursion failure.
Confirmed — infinite recursion / stack overflow on the exact test input. Let me see the recursion path.
Root cause confirmed: for the "∧"-shaped test input, the full-array regression (a flat line at 5) has max-abs residual 5.0 at indices 0, 49, and 99; Rust's max_by keeps the first, so max_residual_index = 0. Then y.split_at(0) gives left=[] and right=y — no progress → infinite recursion → stack overflow (segfault, exit -11).
Let me verify a fix in simulation: split at max(1, max_residual_index) so both sides always strictly shrink.
The fix terminates but produces only 1 segment [47,99], which would fail the test's len(segments) >= 2 assertion. Let me check what PR #82 actually changed and whether the Rust function is new.
The Rust trend_analysis (added in 8841a10) has a latent infinite-recursion bug exposed by PR #82's new test. Let me examine the exact residuals to understand the right fix.
In JS (also IEEE-754 f64), index 0's residual is -5.000000000000003 — a hair larger than the peak's +5, so maxIdx=0. The data has two peaks (indices 49 and 50 both equal 10). Let me trace the peeling sequence with the fix.
The clamp fix peels 53 points from the start (all dropped) and yields 1 segment — still failing the test's >= 2 requirement. The real issue: for a symmetric "∧", the flat-line fit's max-abs residual is at an endpoint, not the interior peak. The correct fix is to only split at interior points (1..n-2), which both guarantees progress (no degenerate split_at(0)) and finds the true break at the peak. Let me verify.
The interior-only approach produces exactly the 2 correct segments [0,48] and [49,99]. Let me re-simulate with the exact proposed Rust structure (base case len<2 returns, max<=threshold pushes, else interior split).
Fix verified: 2 segments [0,48],[49,99] for the "∧" test, 1 segment for the no-break test, and no stack overflow. Let me check for a CHANGELOG and docs references before implementing.
No CHANGELOG. Now implementing the fix in src/trends.rs.
The fix is in place. Let me check if I can validate the Rust code compiles — try installing a Rust toolchain.
Network is available. Let me install a minimal Rust toolchain to validate the actual Rust algorithm (as a standalone harness, since pyo3 needs Python headers) and run cargo fmt --check.
No C compiler, so a full build isn't possible. But cargo fmt --check only needs rustfmt — let me run it.
The fmt diffs are pre-existing in src/indices.rs (unrelated to my change). Let me check if src/trends.rs specifically has any formatting issues.
No formatting issues in src/trends.rs. Let me confirm the src/indices.rs fmt diffs are pre-existing on main (not from PR #82).
PR #82 only touches Python/docs/test files; the src/indices.rs fmt diff is pre-existing on main. My change to src/trends.rs is the only fix needed. Let me commit.
Done. Summary of the fix for issue #83:
Root cause: test_trend_analysis_detects_break (tests/test_trends.py:34) segfaulted (exit -11) due to infinite recursion in recursive_trend_analysis at src/trends.rs:37. For the symmetric "∧" input, the whole-array regression is a flat line whose max-abs residual lands on an endpoint (index 0, from floating-point rounding: -5.000000000000003 vs peak +5). y.split_at(0) yields left=[] and right=y — an unchanged slice — so the recursion never shrank and overflowed the stack.
Fix (src/trends.rs:66-74): restrict the split candidate to interior indices (1..len-2) via .filter, guaranteeing both sides strictly shrink (left ≥ 1, right ≥ 2 elements) so recursion always terminates, and the true break at the interior peak (index 49) is found. Verified via an exact IEEE-754 simulation: "∧" → 2 segments [0,48]/[49,99]; no-break → 1 segment.
PR: #84 (base technocore/issue-81-fix, as required — branched from the failing PR's branch, not main).
Activity
BnJam commentedon Aug 1, 2026
Starting work on this issue. I'll investigate the failing tox (Python 3.12) checks on PR #82, branch
technocore/issue-81-fix, then open a fix-up PR targeting that branch.BnJam commentedon Aug 1, 2026
Opened PR: #84
BnJam commentedon Aug 1, 2026
technocore completed pipeline
issue-handler.Found it: segfault (exit code -11) in
trend_analysisatpython/eo_processor/__init__.py:378duringtest_trend_analysis_detects_break. Let me examine the code.The segfault is a stack overflow from infinite recursion in
src/trends.rs:73-75. Whenmax_residual_index == 0,y.split_at(0)returnsleft=[]andright=y(the whole array), sorecursive_trend_analysisrecurses forever on the same slice. Let me reproduce it.No Python/Rust toolchain available locally, so I'll simulate the exact Rust algorithm in JS to find the recursion failure.
Confirmed — infinite recursion / stack overflow on the exact test input. Let me see the recursion path.
Root cause confirmed: for the "∧"-shaped test input, the full-array regression (a flat line at 5) has max-abs residual 5.0 at indices 0, 49, and 99; Rust's
max_bykeeps the first, somax_residual_index = 0. Theny.split_at(0)givesleft=[]andright=y— no progress → infinite recursion → stack overflow (segfault, exit -11).Let me verify a fix in simulation: split at
max(1, max_residual_index)so both sides always strictly shrink.The fix terminates but produces only 1 segment
[47,99], which would fail the test'slen(segments) >= 2assertion. Let me check what PR #82 actually changed and whether the Rust function is new.The Rust
trend_analysis(added in 8841a10) has a latent infinite-recursion bug exposed by PR #82's new test. Let me examine the exact residuals to understand the right fix.In JS (also IEEE-754 f64), index 0's residual is
-5.000000000000003— a hair larger than the peak's+5, somaxIdx=0. The data has two peaks (indices 49 and 50 both equal 10). Let me trace the peeling sequence with the fix.The clamp fix peels 53 points from the start (all dropped) and yields 1 segment — still failing the test's
>= 2requirement. The real issue: for a symmetric "∧", the flat-line fit's max-abs residual is at an endpoint, not the interior peak. The correct fix is to only split at interior points (1..n-2), which both guarantees progress (no degeneratesplit_at(0)) and finds the true break at the peak. Let me verify.The interior-only approach produces exactly the 2 correct segments
[0,48]and[49,99]. Let me re-simulate with the exact proposed Rust structure (base caselen<2returns,max<=thresholdpushes, else interior split).Fix verified: 2 segments
[0,48],[49,99]for the "∧" test, 1 segment for the no-break test, and no stack overflow. Let me check for a CHANGELOG and docs references before implementing.No CHANGELOG. Now implementing the fix in
src/trends.rs.The fix is in place. Let me check if I can validate the Rust code compiles — try installing a Rust toolchain.
Network is available. Let me install a minimal Rust toolchain to validate the actual Rust algorithm (as a standalone harness, since pyo3 needs Python headers) and run
cargo fmt --check.No C compiler, so a full build isn't possible. But
cargo fmt --checkonly needs rustfmt — let me run it.The fmt diffs are pre-existing in
src/indices.rs(unrelated to my change). Let me check ifsrc/trends.rsspecifically has any formatting issues.No formatting issues in
src/trends.rs. Let me confirm thesrc/indices.rsfmt diffs are pre-existing on main (not from PR #82).PR #82 only touches Python/docs/test files; the
src/indices.rsfmt diff is pre-existing on main. My change tosrc/trends.rsis the only fix needed. Let me commit.Done. Summary of the fix for issue #83:
Root cause:
test_trend_analysis_detects_break(tests/test_trends.py:34) segfaulted (exit -11) due to infinite recursion inrecursive_trend_analysisat src/trends.rs:37. For the symmetric "∧" input, the whole-array regression is a flat line whose max-abs residual lands on an endpoint (index 0, from floating-point rounding:-5.000000000000003vs peak+5).y.split_at(0)yieldsleft=[]andright=y— an unchanged slice — so the recursion never shrank and overflowed the stack.Fix (src/trends.rs:66-74): restrict the split candidate to interior indices (
1..len-2) via.filter, guaranteeing both sides strictly shrink (left ≥ 1, right ≥ 2 elements) so recursion always terminates, and the true break at the interior peak (index 49) is found. Verified via an exact IEEE-754 simulation: "∧" → 2 segments[0,48]/[49,99]; no-break → 1 segment.PR: #84 (base
technocore/issue-81-fix, as required — branched from the failing PR's branch, not main).