How to reproduce:

• Start the secret key export of a key with at least one subkey.
• Cancel the passphrase input that asks for the passphrase protecting the primary key.

Expected result: The secret key export is canceled.

Actual result: A passphrase input asking for the passphrase protecting the (first) subkey is shown.

Example:

$ gpg --status-fd 1 --export-secret-keys --armor -- 3A8536D46F57779C49F0CF542C0444CB59852D29
[GNUPG:] KEY_CONSIDERED 3A8536D46F57779C49F0CF542C0444CB59852D29 0
[GNUPG:] PINENTRY_LAUNCHED 6899 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0
gpg: key 79BF2044FA53B3A492B361882353B5828F9B391C: error receiving key from agent: Operation cancelled - skipped
[GNUPG:] ERROR export_keys.secret 83886179
[GNUPG:] PINENTRY_LAUNCHED 6907 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0
-----BEGIN PGP PRIVATE KEY BLOCK-----

nIsEX+Bq3xIKKwYBBAGXVQEFAQEHQDSKsmsDttOBBZ8Yk95cpMF3QNK9NpbCK2Mk
[...]
=6e8K
-----END PGP PRIVATE KEY BLOCK-----
[GNUPG:] EXPORT_RES 1 1 0

If the result of the export was usable, then it might make sense to continue the export. But the result is not usable (by gpg) because the private key block consists of a secret sub key packet with corresponding signature packet and nothing else. gpg --import cannot import the result of the export.

Also note that EXPORT_RES reports that 0 keys have been exported. So even the secret key export thinks the result should be empty.

Therefore, I think that gpg should abort/skip the export of the entire key and continue with the export of the next key (if there is another key to export).