[neilmartin83]

Problem

Jamf Pro computes no hash for some large packages even after cloudTransferStatus is READY (reported in grahampugh/jamf-upload#418). Wire-checked on a Jamf Pro tenant reporting MD5 only:

	300 MB	2 GB
create	md5 populated within the first polls	READY, every hash field empty, never filled
replace (300 MB → 2 GB, same filename)		old md5 kept ~6 min during transfer, then cleared when size flipped; no new hash

Before this change pro packages upload polled for the full 10 minutes and ended on a generic "timed out" warning, exit 0.

Change

• Once the package is READY at the new file's size and no matching hash is present, allow a 20s grace (verifyGrace), then report the upload as unverified instead of waiting out verifyTimeout.
• The warning distinguishes create, replace (previous hash cleared or left stale), and a replace where old and new sizes are identical, which size cannot confirm.
• Exit code is unchanged (0, the file was uploaded). A hash mismatch still fails as before.
• previousHashes records the record's prior size; fileHashes carries the local byte length.

Stacked

Based on feat/select-extra-columns (#455) so the termSafe(err) change on the same WARNING: line in #453 does not conflict. Merge after #455; the diff here is only pro_packages_upload.go and its test.

Testing

• TestVerifyPackageUpload_UnverifiedWhenREADYAtTheRightSize covers the three cases and asserts the wait ends at the grace, not the timeout.
• go test -count=1 ./internal/commands, make lint (0 issues), make fmt clean.
• Live, with a binary built from this branch at its first commit (45s grace, before it was shortened to 20s), against random 300 MB and 2 GB files (test packages since deleted). Poll counts below are at 45s; the warnings and the verified paths are unaffected by the shorter grace, which was not re-run live:
  • Create 2 GB: "READY and its size matches (2147483648 bytes), but Jamf Pro computed no hash for it; integrity NOT verified", after 7 polls.
  • Replace 2 GB with an identical-size file: "replaced by a file of identical size (2147483648 bytes), so the replace cannot be confirmed by size, and Jamf Pro computed no new hash; integrity NOT verified", after 6 polls.
  • Replace 300 MB with 2 GB: "…computed no hash for it (the previous hash was cleared or left stale by the replace); integrity NOT verified". The old MD5 lingered ~12 polls while READY, which is why the grace only starts once the size matches.
  • Replace 2 GB with 300 MB: verified normally ("Verified: server hash matches local hash") on the first poll, no warning.
  • Create 300 MB: verified on the first poll.
  • All exited 0 and none waited out the 10-minute timeout.
• Grace is 20s because both 300 MB cases were verified on the first poll. Only a 300 MB size was measured on one tenant (MD5-only, S3-style); mid sizes between 300 MB and 1 GB are unmeasured.

🤖 Generated with Claude Code