#199 test fix for uploaded files#201
Conversation
The only additions are: - EncryptKeycode() in encrypt.go (PGP-armored keycode encryption) - PublicKey, PublicKeysResponse, Recipient types in misc.go - GetPublicKeys(), UploadKeycode(), UploadKeycodes() in package.go (all using packageCode in URLs) - The UploadKeycodes() call in the upload flow before FinalizePackage()
| fmt.Printf("File uploads complete\n") | ||
|
|
||
| fmt.Println("Uploading keycodes...") | ||
| if err := p.UploadKeycodes(); err != nil { |
There was a problem hiding this comment.
Not a blocker: wondering whether a keycode upload failure should be fatal here. If SendSafely has no PGP public keys configured for this package (empty PublicKeys slice), UploadKeycodes returns nil and we proceed to finalize. That seems right. But if there are recipients and all keycodes fail, we abort before FinalizePackage. Is that the intended behavior, or would it be better to finalize anyway and let the caller decide? I don't know the SendSafely semantics well enough to say.
| if _, err := io.WriteString(w, keyCode); err != nil { | ||
| return "", fmt.Errorf("failed to write keycode: %w", err) | ||
| } | ||
| w.Close() |
There was a problem hiding this comment.
w.Close() and armorWriter.Close() (line 92) return errors that are dropped here. In practice these write to a bytes.Buffer which cannot fail, so this is probably safe. The existing encrypt() above does the same thing. Would it make sense to check both and return an error, at least for defensive consistency? Or is the pattern intentional given the buffer-backed writer?
eugeneckim
left a comment
There was a problem hiding this comment.
go_debug.txt (763 lines) and yb-support-tool (binary, 13 MB) are both included in the commit. Neither should be version-controlled. The debug file ends with a DENIED response from the keycode upload endpoint — is there a successful end-to-end run somewhere that confirms the full flow works? Happy to be corrected if the package expiry explains the DENIED.
The only additions are: