fix(vk): publish complete PNG captures and report failures #1604
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!1604
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/png-publication"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 main779bdcf: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 main779bdcf. Earlier local/runtime results describe their recorded source hashes.Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.