feat: implement _from_protobuf for schedule transactions (from_bytes round-trip)

[exploreriii]

🧑‍🔬 Advanced Issue

Welcome! This is an Advanced Issue touching core SDK architecture.

It is designed for expert contributors who have demonstrated deep architectural understanding and a proven track record of high-quality contributions.

🐞 Problem Description

Transaction.from_bytes() returns a correctly-typed but empty instance for the transaction types below: they never override _from_protobuf, so every type-specific field is left at its default with no error or warning (common fields, signatures and the original body bytes are restored by the base class, so execution still works — inspection does not). Part of #2179; the dispatch-map fixes and the round-trip test harness land in #2614 first.

Affected classes:

• ScheduleCreateTransaction (src/hiero_sdk_python/schedule/schedule_create_transaction.py)
• ScheduleSignTransaction (src/hiero_sdk_python/schedule/schedule_sign_transaction.py)
• ScheduleDeleteTransaction (src/hiero_sdk_python/schedule/schedule_delete_transaction.py)

💡 Expected Solution

Implement _from_protobuf for each affected class as the exact field-for-field inverse of its build_transaction_body(), then remove the xfail markers for these types in the round-trip harness from #2614.

• ScheduleCreateTransaction._from_protobuf
• ScheduleSignTransaction._from_protobuf
• ScheduleDeleteTransaction._from_protobuf
• Un-xfail these types in the fix: correct the from_bytes transaction-type dispatch map and add a round-trip test harness #2614 round-trip harness

🔍 Background Research

This is inverse-serialization contract work — please research the pattern before coding; do not code from this issue title alone, and do not ship the first AI-generated attempt that runs. Reviewers check inverse fidelity per field.

1. Issue Transaction.from_bytes() returns incomplete objects for most transaction types — missing _from_protobuf implementations #2179 (context) and fix: correct the from_bytes transaction-type dispatch map and add a round-trip test harness #2614 (the test harness your PR must satisfy — do not start before it is merged).
2. The reference implementations: FileCreateTransaction._from_protobuf (src/hiero_sdk_python/file/file_create_transaction.py) and TransferTransaction._from_protobuf (src/hiero_sdk_python/transaction/transfer_transaction.py). Your implementation must follow their structure exactly: call super()._from_protobuf(...), then restore type-specific fields from the body.
3. Each affected class's build_transaction_body() — your _from_protobuf is its exact inverse. Reuse the SDK's existing _from_proto converters (AccountId, TokenId, keys, …); never hand-parse a submessage that already has one.
4. The generated proto message for each body (src/hiero_sdk_python/hapi/services/) — learn which fields are optional (guard with HasField so unset stays None) versus plain scalars/repeated.
5. CONTRIBUTING.md for test and PR conventions.

🛠️ Implementation Notes

ScheduleCreateTransaction is the hardest case in #2179: its body embeds a SchedulableTransactionBody (the inner scheduled transaction). Research how schedule_info.py and the other SDKs (JS/Java ScheduleCreateTransaction.fromProtobuf) handle the inner body before deciding on an approach, and explain your choice in the PR.

Constraints / acceptance criteria:

• For each class: build with all fields set → freeze → to_bytes() → from_bytes() → every type-specific field equals the original
• Unset optional fields come back as None/empty, not proto defaults
• restored.to_bytes() stays byte-identical to the original (no re-serialization of the body)
• No changes to public API signatures

Part of #2179. Blocked by #2614.

🔬 Technical Domains

• API Client Architecture (request → serialization → execution → response mapping)
• Backward Compatibility (preserving method signatures, defaults, and return types)
• Protobuf Alignment (reading .proto files, _to_proto() / _from_proto() correctness)
• State & Immutability (correct usage of guards like _require_not_frozen)
• Execution Boundaries (retry logic, backoff, node selection, gRPC deadlines)
• Testing (unit, integration, mocking, test coverage for edge cases and failure modes)

🧠 Advanced Contributors — Prerequisites & Expectations

Caution

Advanced issues are the highest-risk work in this project. We will reject PRs that do not meet these standards.

🏁 Concrete Prerequisites

• Advanced Language: Proficient with Python.
• Expertise: Deep architectural understanding of _Executable, Transaction, and Query base classes.
• Proven History: Successfully completed ≥ 10 intermediate issues in this repo.
• Consistency: ≥ 3–4 months of active, human-led contributions to this SDK.

⚠️ AI Usage Policy

• Using AI to generate code for Advanced issues is strictly discouraged
• AI may be used to help explain file relationships, but cannot be the main source of research.
• Submitting AI-generated or unvalidated code is grounds for immediate closure

⏱️ Timeline & Workflow

• Typical time: ~1 month / ~50 hours.
• 🔴 Completing an advanced issue in 1–3 days is a red flag and will likely be rejected.
• Suggested: Post your proposed architectural approach as a comment and wait for explicit maintainer approval before writing any code.

🛡️ Quality & Review Standards

Advanced PRs must be "safe, maintainable, architecturally sound, and production-ready."

1. Architectural Fit: The solution must fit naturally into the existing SDK abstractions.
2. Security & Correctness: Evaluate all logic for injection risks, state corruption, or thread-safety issues.
3. Maintainability: Code must be short and clear enough for any other maintainer to debug without your assistance.
4. Backward Compatibility: Public API signatures must be preserved. If a breaking change is required, it must be explicitly managed through a deprecation cycle.
5. Comprehensive Testing: Must include unit and integration tests covering all new logic paths, edge cases, and failure modes. AI generated tests based on AI generated code is grounds for immediate rejection.

✅ PR Quality Checklist

Before opening your PR, the contributor must confirm:

• I have spent the majority of my time researching the problem and solution space extensively, including reviewing relevant code, documentation, and external resources.
• I understand the system-wide impact of these changes on affected modules and performance.
• The system design fits with current Hiero SDK architectural approaches.
• I have tested my changes extensively against both local and network environments.
• I have verified naming, types, and field ordering against pinned Protobufs.
• Every line of code is personally understood and explainable.

📚 Resources & Support

References:

• Hedera Protobufs

Python SDK References:

• SDK Project Structure
• Transaction Lifecycle
• Executable Architecture
• Hedera Protobufs (services)
• Browse closed advanced PRs — see how others did it

🆘 Stuck?

• Community Calls
• Discord

[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

[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.