Repository navigation
26.11.1.post2: native wheel with a Windows-safe release gate, plus #340 #347
Description
26.11.1.post1 is half published: arcadedb-jvm 26.11.1.post1 is on PyPI; the native arcadedb is not, because its release run failed the Windows parity legs for Python 3.11 and 3.14 (a silent process death inside one test file per leg, the family of #295; two attempts of the same wheel). The crash did not reproduce in 360 isolated runs of the two files (6 combinations of wheel and Python, 30 runs per file) nor in 18 full Windows parity legs with diagnostics (3 wheels, 2 Pythons, 3 repetitions: 12 post1 legs all passed). A control run with the release's exact configuration (tag checkout, stock harness, no diagnostics, release-run wheel, 5 repetitions per Python) is in progress. The release workflows run from the files at the tag, so a CI change can only ship in a new tag: this is why the next patch is 26.11.1.post2, which publishes both packages at the same version.
Acceptance
- Windows crash handling in the parity harness (CI and tests only, no wheel code): record the exit code (
CRASH(rc=0x...)), keepfaulthandlerenabled on Windows with output to a file so the crash site is captured, retry a crashed file ONCE in a fresh process, report any retry asFLAKY-CRASHin the job summary and as a comment on Windows 3.14 native parity: test_vector.py process died silently once on main #295, and fail the leg when a file crashes twice. Test failures stay strict; Linux and macOS stay strict. - Decide from the control run whether the cause is the stock harness configuration (faulthandler disabled and fd capture on Windows) and record it on Windows 3.14 native parity: test_vector.py process died silently once on main #295. Done: the control run (42758616458) was clean in all 10 legs, so the stock configuration is not the cause by itself; recorded on Windows 3.14 native parity: test_vector.py process died silently once on main #295.
- to_dataframe: an integer above 2**53 next to a float is rounded by pandas, the other readers keep it exact #340:
to_dataframeexactness for an integer above 2**53 next to a float. - Anything the matched-durability probe and the JVM
verticesfollow-up decide (the follow-up showed the partial-call outcome is the released behaviour; the post1 docs now say so). - Full-matrix dispatch on the exact commit (test-jvm, test-native, examples), the engine identity guard on the CI-built wheels, then the tag
26.11.1.post2; verify both packages on PyPI. - The mini rerun of the paper's ingest cells uses the post2 native wheel.
Activity
integration: merge perf/jvm-arrow-vector-conversion (9914e93: float32…
tae898 commentedon Nov 10, 2026
The tag
26.11.1.post2is pushed on1454809(integration/post2-candidate). The release runs are native 42804220685 and JVM 42804220687. Before the tag, the three full-matrix dispatches on this exact commit passed: Test JVM, Test native and Test Python Examples.What the tag carries on top of
26.11.1.post1:FLAKY-CRASHreported on Windows 3.14 native parity: test_vector.py process died silently once on main #295, a file that dies twice fails the release;to_dataframe()keeps an integer beyond 2**53 next to a float exact (to_dataframe: an integer above 2**53 next to a float is rounded by pandas, the other readers keep it exact #340);26.11.1.On PyPI:
arcadedb-jvm 26.11.1.post2(4 wheels, first upload 2026-11-10 11:55 UTC) andarcadedb 26.11.1.post2(4 wheels, first upload 2026-11-10 12:25 UTC), none yanked.I ran my verification script on the published files of both packages: 30 checks passed and 0 failed. It compares the sha256 of every wheel on PyPI with the wheel of the release run, checks that the engine part is identical to the
26.11.1finals, runs a SQL and an openCypher query in a freshuvenvironment per package and Python version, checks thatuv addresolves26.11.1.post2, and runs the #340 case. Nothing is yanked.Not in this tag: the matched-durability follow-up and anything the timed study of the vector conversion has not decided yet (#348 carries the memory side).
One crash outside this release is recorded in #352: the JVM wheel hit a HotSpot access violation once in a Windows examples run on this commit, and the rerun of that job passed.
The release line is merged into
mainin #351 (merge commit6619f13), and the GitHub Release page has the change list of this tag. I am closing this issue.CI: Windows parity harness records crash exit codes, keeps a trace an…
integration: merge ci/post2-windows-crash-retry (aa223d0: Windows-onl…
integration: merge fix/340-to-dataframe-int64-exact (4d2db17: to_data…
Merge the 26.11.1.post2 release line into main