Skip to content

Invio v1.0.0.1.38

Choose a tag to compare

@github-actions github-actions released this 10 Aug 13:10
· 31 commits to main since this release

Invio v1.0.0.1.38 — P14 WiX Debug-Symbol Release Inventory Correction

Status

  • P11: IMPLEMENTED / LIVE ACCEPTANCE PENDING
  • P14: CERTIFICATION PENDING
  • Completed acceptance phases: 12/14
  • Production-ready: NO
  • SQLite schema: v5 unchanged
  • Runtime dependencies: unchanged
  • Provider send/business behavior: unchanged
  • WorkerManager / Task architecture: unchanged
  • UI/UX and page inventory: unchanged

Audited GitHub failure

GitHub Actions run 31386258538, Windows job 93447256779, checked out commit fca2da3e4bb6d19687f2c85f48911d7ade7501ba.

The Windows job passed the full 383/383 regression audit, workflow version mapping, wheel build/install, native PySide6/keyring/resource smoke, Nuitka OneDir build, portable preparation, compiled OneDir startup smoke, WiX 6.0.2 installation, MSI build, and MSI clean install/run/uninstall smoke.

Failure occurred in Assemble release payloads and checksums. WiX had emitted its default sibling debug-symbol file:

Invio_v1.0.0.1.37_windows_x64_setup.wixpdb

The checksum writer intentionally included every file in dist/release, producing four checksum entries. The distribution auditor intentionally accepts only the frozen release payloads: portable ZIP, MSI and wheel, plus SHA256SUMS.txt. The mismatch was therefore one unexpected .wixpdb sidecar, not four incorrect hashes.

v1.38 correction

The existing WiX build command now adds the documented -pdbtype none option. This prevents the debug .wixpdb sidecar from being emitted beside the MSI while leaving the MSI itself and all release topology unchanged.

The checksum writer and distribution auditor are deliberately unchanged so they continue to fail closed if any unexpected payload enters dist/release.

Certification truthfulness

The v1.37 run provides successful external evidence through MSI build and MSI install/run/uninstall, but it failed before final checksum audit and artifact upload. Therefore P14 remains CERTIFICATION PENDING. The exact pushed v1.38 Windows workflow must complete checksum audit and artifact upload successfully, and owner-controlled Stripe/Refrens live acceptance gates remain required before any production-ready claim.