Refactor FileCreateTransaction to use `Key` instead of `PublicKey`

[manishdait]

FileCreateTransaction currently uses PublicKey in set_keys(), even though it could support any Key subtype. refactor the implementation to use Key as the accepted type.

[github-actions]

Thanks for your submission.

This issue is awaiting approval from @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

Approved by @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Broaden FileCreateTransaction's constructor, keys field, and set_keys() from PublicKey to the abstract Key type, updating the runtime isinstance branch accordingly.
• Route serialization through the shared key_to_proto() helper and deserialization through Key.from_proto_key(), replacing the PublicKey-specific private methods.
• Update and extend unit tests to cover PrivateKey and KeyList inputs while keeping existing PublicKey behavior backward compatible.
• Keep FileUpdateTransaction out of scope per the ticket, noting it as a potential follow-up.

Design Choices

Design Choice 1: Should FileUpdateTransaction be refactored in the same change?

Options Considered:

1. Refactor only FileCreateTransaction as the ticket states.
2. Also refactor FileUpdateTransaction for consistency.

Chosen Option: 1

Rationale: The exploration notes FileUpdateTransaction shares the identical PublicKey-only pattern, but the ticket names only FileCreateTransaction. The ticket scope is explicitly FileCreateTransaction; FileUpdateTransaction can be addressed in a follow-up to avoid scope creep.

Design Choice 2: How should protobuf conversion be performed?

Options Considered:

1. Call key.to_proto_key() directly on each key.
2. Use the shared key_to_proto() helper from utils/key_utils.py.

Chosen Option: 2

Rationale: Precedents use two idioms: direct key.to_proto_key() (account) vs. the shared key_to_proto() helper (token/topic). The helper provides centralized TypeError validation and matches the most recent token/topic transaction convention.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Generalize FileCreateTransaction to the Key abstraction

This phase broadens the transaction's public API and internal protobuf handling from the concrete PublicKey type to the polymorphic Key type, following the pattern established by account/token/topic transactions. The goal is to accept any Key subtype on input, serialize it through the shared conversion helper, and reconstruct any key variant on deserialization.

Task 1: Broaden type hints and setter logic to accept Key

Update the transaction's constructor, instance field, and setter to use the abstract Key type.

• In src/hiero_sdk_python/file/file_create_transaction.py, add from hiero_sdk_python.crypto.key import Key and retire the direct dependency on PublicKey where it was only used for typing/branching.
• Change the constructor parameter and self.keys attribute annotations from list[PublicKey] | None to list[Key] | None.
• Change set_keys() signature to keys: list[Key] | Key | None and update its runtime branch from isinstance(keys, PublicKey) to isinstance(keys, Key), so a single Key of any subtype is wrapped in a list while a list/None is assigned as-is.
• Note the intentional behavior: because KeyList is itself a Key, passing a bare KeyList is treated as one key (wrapped in a list), not unpacked — this is correct and should be preserved.

Task 2: Route protobuf serialization/deserialization through the generic Key API

Replace the PublicKey-specific private methods with the polymorphic public interface.

• In _build_proto_body(), replace key._to_proto() with the shared helper key_to_proto(key) (import from hiero_sdk_python.utils.key_utils) for each element when building the KeyListProto, matching the token/topic transaction pattern and gaining its TypeError validation for non-Key inputs.
• In _from_proto(), replace PublicKey._from_proto(key) with Key.from_proto_key(key) so deserialization can reconstruct any key variant (PublicKey, KeyList, ContractId, etc.), not just raw public keys.

🤖 Prompt for AI agents

Implement the refactor of `FileCreateTransaction` in
`src/hiero_sdk_python/file/file_create_transaction.py` so it uses the generic
`Key` abstraction instead of the concrete `PublicKey` type, matching the pattern
used by account/token/topic create transactions.

- Add `from hiero_sdk_python.crypto.key import Key` to the file, and remove the
direct dependency on `PublicKey` where it was only used for typing/branching.
- Change the constructor parameter and the `self.keys` attribute annotations
from `list[PublicKey] | None` to `list[Key] | None`.
- Change the `set_keys()` method signature to accept `keys: list[Key] | Key |
None`. Update the runtime check inside from `isinstance(keys, PublicKey)` to
`isinstance(keys, Key)` so that a single `Key` of any subtype gets wrapped into
a list, while a list or `None` is assigned as-is.
- Preserve the intentional behavior that a bare `KeyList` (itself a `Key`)
passed to `set_keys()` is treated as a single key and wrapped in a list, not
unpacked into its members.
- In `_build_proto_body()`, replace calls to `key._to_proto()` with the shared
helper `key_to_proto(key)` imported from `hiero_sdk_python.utils.key_utils`,
applied to each key when building the `KeyListProto`. This mirrors the
token/topic transaction pattern and adds `TypeError` validation for non-`Key`
inputs.
- In `_from_proto()`, replace `PublicKey._from_proto(key)` with
`Key.from_proto_key(key)` so deserialization reconstructs any key variant (e.g.,
PublicKey, KeyList, ContractId), not only raw public keys.

Phase 2: Update unit tests for the generalized key handling

This phase adjusts existing tests coupled to PublicKey and adds coverage proving that other Key subtypes are accepted, keeping the suite representative of the new contract while preserving backward compatibility for existing PublicKey usage.

Task 1: Update existing key-type assertions and imports

Loosen PublicKey-specific assumptions where the API is now generic.

• In tests/unit/file_create_transaction_test.py, add imports for Key (hiero_sdk_python.crypto.key) and KeyList (hiero_sdk_python.crypto.key_list).
• Update test_set_keys_variations so its single-key branch relies on the generalized isinstance(..., Key) behavior rather than PublicKey specifically.
• Update the _from_proto output assertion in test_file_create_transaction_from_proto to assert against the appropriate reconstructed type (generic Key, while still valid for the PublicKey case produced by ed25519/ECDSA proto entries).

Task 2: Add coverage for additional Key subtypes

Prove the broadened contract works for non-PublicKey inputs.

• Add test cases passing a PrivateKey and a real KeyList instance to set_keys() (both single and list forms), verifying they are stored/wrapped correctly and serialize without error through _build_proto_body().
• Verify the KeyList-as-single-key case is treated as one key rather than being unpacked.
• Optionally add a pytest.raises(TypeError) case for an invalid (non-Key) input, exercising the validation now provided by key_to_proto().

🤖 Prompt for AI agents

Update `tests/unit/file_create_transaction_test.py` to reflect and cover the
generalized `Key`-based API of `FileCreateTransaction`.

- Add imports for `Key` (from `hiero_sdk_python.crypto.key`) and `KeyList` (from
`hiero_sdk_python.crypto.key_list`).
- Update `test_set_keys_variations` so the single-key branch of the test relies
on the generalized `isinstance(..., Key)` behavior rather than checking
specifically for `PublicKey`.
- Update the assertion on the `_from_proto` output in
`test_file_create_transaction_from_proto` to assert against the appropriate
reconstructed type — generic `Key`, while remaining valid for the `PublicKey`
case produced by ed25519/ECDSA proto entries.
- Add new test cases that pass a `PrivateKey` and a real `KeyList` instance into
`set_keys()`, in both single-key and list forms, verifying correct
storage/wrapping and successful serialization via `_build_proto_body()`.
- Add a test verifying that passing a bare `KeyList` to `set_keys()` results in
it being treated as a single key (wrapped in a list) rather than unpacked into
its members.
- Optionally add a test using `pytest.raises(TypeError)` for an invalid,
non-`Key` input, to exercise the validation now provided by `key_to_proto()`.

Research

FileCreateTransaction (src/hiero_sdk_python/file/file_create_transaction.py) currently type-hints its keys field and set_keys() setter as PublicKey, branches on isinstance(keys, PublicKey), and serializes each key via the private PublicKey._to_proto() method while deserializing via PublicKey._from_proto. The crypto module defines an abstract Key base class (crypto/key.py) with to_proto_key() and the from_proto_key() factory; PublicKey, PrivateKey, and KeyList all inherit from it. Established precedents (account_create_transaction.py, token_create_transaction.py, topic_create_transaction.py) already type key inputs as Key and convert through the shared key_to_proto() helper (utils/key_utils.py). The refactor aligns FileCreateTransaction with this established pattern.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the refactor of `FileCreateTransaction` in
`src/hiero_sdk_python/file/file_create_transaction.py` so it uses the generic
`Key` abstraction instead of the concrete `PublicKey` type, matching the pattern
used by account/token/topic create transactions.

- Add `from hiero_sdk_python.crypto.key import Key` to the file, and remove the
direct dependency on `PublicKey` where it was only used for typing/branching.
- Change the constructor parameter and the `self.keys` attribute annotations
from `list[PublicKey] | None` to `list[Key] | None`.
- Change the `set_keys()` method signature to accept `keys: list[Key] | Key |
None`. Update the runtime check inside from `isinstance(keys, PublicKey)` to
`isinstance(keys, Key)` so that a single `Key` of any subtype gets wrapped into
a list, while a list or `None` is assigned as-is.
- Preserve the intentional behavior that a bare `KeyList` (itself a `Key`)
passed to `set_keys()` is treated as a single key and wrapped in a list, not
unpacked into its members.
- In `_build_proto_body()`, replace calls to `key._to_proto()` with the shared
helper `key_to_proto(key)` imported from `hiero_sdk_python.utils.key_utils`,
applied to each key when building the `KeyListProto`. This mirrors the
token/topic transaction pattern and adds `TypeError` validation for non-`Key`
inputs.
- In `_from_proto()`, replace `PublicKey._from_proto(key)` with
`Key.from_proto_key(key)` so deserialization reconstructs any key variant (e.g.,
PublicKey, KeyList, ContractId), not only raw public keys.
===============================================================================

Task: 2

Update `tests/unit/file_create_transaction_test.py` to reflect and cover the
generalized `Key`-based API of `FileCreateTransaction`.

- Add imports for `Key` (from `hiero_sdk_python.crypto.key`) and `KeyList` (from
`hiero_sdk_python.crypto.key_list`).
- Update `test_set_keys_variations` so the single-key branch of the test relies
on the generalized `isinstance(..., Key)` behavior rather than checking
specifically for `PublicKey`.
- Update the assertion on the `_from_proto` output in
`test_file_create_transaction_from_proto` to assert against the appropriate
reconstructed type — generic `Key`, while remaining valid for the `PublicKey`
case produced by ed25519/ECDSA proto entries.
- Add new test cases that pass a `PrivateKey` and a real `KeyList` instance into
`set_keys()`, in both single-key and list forms, verifying correct
storage/wrapping and successful serialization via `_build_proto_body()`.
- Add a test verifying that passing a bare `KeyList` to `set_keys()` results in
it being treated as a single key (wrapped in a list) rather than unpacked into
its members.
- Optionally add a test using `pytest.raises(TypeError)` for an invalid,
non-`Key` input, to exercise the validation now provided by `key_to_proto()`.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!