fix(vk): publish complete PNG captures and report failures #1604

Merged
Arkex-ai merged 1 commit from fix/png-publication into main 2026-11-10 11:25:52 +00:00
Arkex-ai commented 2026-11-10 10:49:12 +00:00 (Migrated from github.com)

A short write or a failed close can replace an older screenshot with an incomplete PNG while the capture thread still reports success. Concurrent first-use CRC initialization can also produce an incorrect chunk checksum.

Publish each complete PNG through an exclusively created temporary in its destination directory, checking every write, close and replacement result. Failed publication preserves the previous destination, attempts cleanup of only the owned temporary, and reports its phase, error code and path with a bounded diagnostic count. The CRC table is immutable after thread-safe initialization; normal capture announces success only when publication succeeds. Later captures can retry normally.

Validation at 7891ae1f07d3f03888d8fb83c10678441733eed5, based on main 779bdcf:

  • Actual baseline PNG/CRC functions: healthy output passes; authored write/close failures replace the previous complete file, and a controlled partial-table initialization interleaving gives an incorrect CRC for the standard 123456789 vector.
  • 25 game-free cases plus the existing capture-dimensions/PNG consumer check pass LLVM, GCC and Linux ASan/UBSan. They cover each write, close, replacement, cleanup, exclusive collisions, retries, concurrent first use/competing writers and success announcements. Independent decoding verifies chunk CRCs, zlib and exact RGB pixels across stored-block boundaries. Eight incorrect variants fail behavioral checks.
  • Complete Windows source suite: 232 passed, 2 failed, 20 skipped; exact main: 231 passed, the same 2 failures and 20 skips. The unchanged local limitations are NUP symlink privileges and unavailable native Windows SDK headers for the precompile guard. No checks were relaxed.
  • Official matching API 12 host/backend build passes with clean guest generation from unchanged main inputs. Two isolated native checkpoint runs exited 0. A temporarily unavailable capture directory produced actual open-error reports without false success; restoring it recovered capture output. Eight normal/generated-frame 3440x1440 PNGs passed CRC, zlib and RGB decoding; no incomplete temporary remained, and original checkpoint hashes stayed unchanged.

This publishes individual files, not a multi-file transaction or power-loss durability guarantee. Full-disk/close errors are simulated; native validation exercised an unavailable output path and recovery. Pixels, compression, capture scheduling and host/renderer ABI are unchanged; no intended visual change. No game files, generated game code, binaries, saves or private runtime logs are included.

Details: docs/png-publication.md. Capture sizing/stage diagnostics (#1541) and control-bridge capture additions (#926/#1025) were checked for overlap; this fixes the shared writer. Exact-head fork source, Windows-builder and AppImage checks are dispatched and will be reported when complete.

Current-head validation

Current head 7891ae1, based on main 779bdcf. Earlier local/runtime results describe their recorded source hashes.

Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.

A short write or a failed close can replace an older screenshot with an incomplete PNG while the capture thread still reports success. Concurrent first-use CRC initialization can also produce an incorrect chunk checksum. Publish each complete PNG through an exclusively created temporary in its destination directory, checking every write, close and replacement result. Failed publication preserves the previous destination, attempts cleanup of only the owned temporary, and reports its phase, error code and path with a bounded diagnostic count. The CRC table is immutable after thread-safe initialization; normal capture announces success only when publication succeeds. Later captures can retry normally. Validation at `7891ae1f07d3f03888d8fb83c10678441733eed5`, based on main `779bdcf`: - Actual baseline PNG/CRC functions: healthy output passes; authored write/close failures replace the previous complete file, and a controlled partial-table initialization interleaving gives an incorrect CRC for the standard 123456789 vector. - 25 game-free cases plus the existing capture-dimensions/PNG consumer check pass LLVM, GCC and Linux ASan/UBSan. They cover each write, close, replacement, cleanup, exclusive collisions, retries, concurrent first use/competing writers and success announcements. Independent decoding verifies chunk CRCs, zlib and exact RGB pixels across stored-block boundaries. Eight incorrect variants fail behavioral checks. - Complete Windows source suite: 232 passed, 2 failed, 20 skipped; exact main: 231 passed, the same 2 failures and 20 skips. The unchanged local limitations are NUP symlink privileges and unavailable native Windows SDK headers for the precompile guard. No checks were relaxed. - Official matching API 12 host/backend build passes with clean guest generation from unchanged main inputs. Two isolated native checkpoint runs exited 0. A temporarily unavailable capture directory produced actual open-error reports without false success; restoring it recovered capture output. Eight normal/generated-frame 3440x1440 PNGs passed CRC, zlib and RGB decoding; no incomplete temporary remained, and original checkpoint hashes stayed unchanged. This publishes individual files, not a multi-file transaction or power-loss durability guarantee. Full-disk/close errors are simulated; native validation exercised an unavailable output path and recovery. Pixels, compression, capture scheduling and host/renderer ABI are unchanged; no intended visual change. No game files, generated game code, binaries, saves or private runtime logs are included. Details: `docs/png-publication.md`. Capture sizing/stage diagnostics (#1541) and control-bridge capture additions (#926/#1025) were checked for overlap; this fixes the shared writer. Exact-head fork source, Windows-builder and AppImage checks are dispatched and will be reported when complete. <!-- goal15-current-validation --> ### Current-head validation Current head `7891ae1`, based on main `779bdcf`. Earlier local/runtime results describe their recorded source hashes. - [Linux AppImage](https://github.com/Arkex-ai/Hookshot/actions/runs/42802334495): success. - [Windows builder](https://github.com/Arkex-ai/Hookshot/actions/runs/42802329864): success. - [Game-free source regressions](https://github.com/Arkex-ai/Hookshot/actions/runs/42802326121): success. Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.
Commenting is not possible because the repository is archived.
No description provided.