testing labels advanced

[DeathGun44]

🧑‍🔬 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

🛠️ Implementation Notes

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

Note

CI/CD Exception: For issues focused on GitHub Actions / Workflows, the repo-specific thresholds above may be waived if the contributor demonstrates advanced-level proficiency in CI/CD.

⚠️ 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.

🔬 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)

🛡️ 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