Bug: add_allin prevents postflop convergence (stalls ~3.5% pot)

[SergMartidi]

add_allin: true stalls postflop CFR convergence (deep SPR); identical spot without all-in converges fine

Summary

On a deep-SPR HU flop spot, enabling tree.add_allin causes DCFR (compressed i16) to stall around ~3.5–4% pot exploitability. The same config with only add_allin: false reaches ≤0.5% pot in ~220 iterations.

Repro configs

Only difference: add_allin.

Shared: AdAc9h, pot 55, stack 975, ranges OOP=IP 22+,A2s+,K9s+,Q9s+,J9s+,T9s,ATo+,KTo+,QJo, bet 50% / raise 100% pot on flop/turn/river, no donk, allin_threshold: 0.85, max_raises: 10.

Without all-in

"allin_threshold": 0.85,
"add_allin": false,
"max_raises": 10

With all-in

"allin_threshold": 0.85,
"add_allin": true,
"max_raises": 10

Full JSON files available if useful (happy to paste/attach).

Commands

SOLVER_MEM_MB=8192 ./target/release/solve-cli spot_without_allin.json 2000 0.5
SOLVER_MEM_MB=8192 ./target/release/solve-cli spot_with_allin.json 2000 0.5
# long run still fails target:
SOLVER_MEM_MB=8192 ./target/release/solve-cli spot_with_allin.json 10000 0.5

Defaults: Compressed storage, DCFR, CPU.

Observed results

Case	Tree	Result
add_allin: false	727 677 nodes (285 288 action), arenas ~529 MB	iter 220 → 0.477% pot in 45.3 s
add_allin: true	1 075 938 nodes (384 470 action), arenas ~774 MB	iter 200 → 3.542%; iter 10000 → 3.873% pot in ~3668 s

With all-in, exploitability improves quickly early, then floors ~3.5% and a 10k-iter run does not beat (and slightly exceeds) the iter-200 reading.

Cross-check

The same board/ranges/sizes with all-in in TexasSolver reached ~0.26% pot in ~391 iterations — spot is solvable elsewhere; failure appears specific to GTOpen + add_allin on this tree.

Environment

• Linux x86_64, solve-cli --release, CPU only, SOLVER_MEM_MB=8192
• Repo: MatthewPDingle/GTOpen

Json's with settings attached.

spot_with_allin.json

spot_without_allin.json