Create an abstract `ChunkedTransaction` base class to centralize chunking transaction logic

[manishdait]

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

We currently have two transactions that support chunked execution, TopicMessageSubmitTransaction and FileAppendTransaction.

Both implementations contain a large amount of duplicated logic related to chunk handling, including:

• Chunk calculation and validation
• Transaction ID generation for chunks
• Multi-chunk execution flow
• Signing management across chunks
• Chunk iteration and state tracking
• Body size calculation for all chunks

Introducing a shared abstraction for chunked transactions would help centralize this logic, reduce duplication, and improve long-term maintainability.

🛠️ Implementation Notes

• Create an abstract ChunkedTransaction base class that wraps the common chunking behavior shared between TopicMessageSubmitTransaction and FileAppendTransaction.
  • Class should possibly contain following fields:
    • self._current_chunk_index
    • self._transaction_ids
    • self._signing_keys
    • self.chunk_size
    • self.max_chunks
  • Add proper setters for them.
  • The class should also potentially centralize the following methods:
    • freeze_with()
    • execute()
    • execute_all()
    • sign()
    • body_size_all_chunks()
    • _validate_chunking()

class ChunkedTransaction(Transaction, ABC):
    ....
    def get_required_chunks(self) -> int:
        # override this form the transaction
        ...

    @abstractmethod
    def _build_proto_body(self):
        pass

• The implementation should ensure that chunk-specific transaction IDs and signatures remain deterministic and compatible with existing behavior and did not cause any breaking changes

🧠 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

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Create a new abstract ChunkedTransaction class in src/hiero_sdk_python/transaction/chunked_transaction.py that sits between Transaction and the concrete chunked transactions in the inheritance hierarchy
• Extract all common chunking fields and methods to the base class while preserving the abstract get_required_chunks() method for subclass-specific content calculation
• Refactor TopicMessageSubmitTransaction and FileAppendTransaction to inherit from ChunkedTransaction, keeping only their domain-specific fields, setters, and proto body building logic
• Maintain full backward compatibility by preserving all public method signatures, default values, and existing behavior patterns

Design Choices

Design Choice 1: Should validation be added to `set_chunk_size` and `set_max_chunks` in the base class?

Options Considered:

1. Add validation to base class (adds stricter validation to FileAppendTransaction)
2. No validation in base class, let Topic override to add validation (preserves exact behavior)

Chosen Option: 1

Rationale: Adding positive-value validation is a safe enhancement that prevents invalid configurations and aligns with defensive programming practices.

Design Choice 2: How should `_initial_transaction_id` be handled given only Topic uses it?

Options Considered:

1. Include _initial_transaction_id in base class, set for all chunked transactions (harmless for FileAppend)
2. Keep _initial_transaction_id only in TopicMessageSubmitTransaction, requiring Topic to override freeze_with

Chosen Option: 1

Rationale: Setting _initial_transaction_id in the base class simplifies the code and is harmless for transactions that don't use it.

💡 User Tips

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

Implementation Steps

Phase 1: Create ChunkedTransaction Base Class

Introduce the abstract base class that encapsulates all shared chunking behavior, establishing the new middle layer in the inheritance hierarchy.

Task 1: Create ChunkedTransaction module

Create the new abstract base class with all shared chunking fields and methods extracted from the existing implementations.

• Create src/hiero_sdk_python/transaction/chunked_transaction.py as the new module
• Define ChunkedTransaction(Transaction, ABC) class with proper imports from typing, abc, and internal modules
• Initialize common chunking state in __init__: _current_chunk_index, _transaction_ids, _signing_keys, _initial_transaction_id (all with appropriate defaults)
• Note: chunk_size and max_chunks should NOT be initialized in base __init__ — subclasses set their own defaults

Task 2: Define abstract method contract

Establish the abstract method that subclasses must implement to provide content-specific chunk calculation.

• Add @abstractmethod for get_required_chunks() -> int — each subclass calculates based on its content field
• Document that this method must return the number of chunks needed for the current content

Task 3: Implement common setters

Add the shared setter methods with appropriate validation and freeze guards.

• Implement set_chunk_size(chunk_size: int) with _require_not_frozen() guard and positive value validation
• Implement set_max_chunks(max_chunks: int) with _require_not_frozen() guard and positive value validation
• Return self to enable method chaining (use appropriate return type annotation)

Task 4: Implement _validate_chunking

Add the validation method that guards against exceeding chunk limits.

• Implement _validate_chunking() that compares get_required_chunks() against max_chunks
• Raise ValueError with a clear message when required chunks exceed the limit
• Use a generic error message suitable for any chunked transaction type

Task 5: Implement freeze_with override

Centralize the transaction ID generation logic for all chunks.

• Override freeze_with(client) with idempotent guard (return early if _transaction_body_bytes non-empty)
• Resolve transaction ID via parent method _resolve_transaction_id(client)
• Generate chunk-specific transaction IDs with nanosecond-staggered timestamps (chunk 0 reuses base ID, subsequent chunks increment nanos with overflow handling)
• Set _initial_transaction_id to chunk 0's transaction ID
• Delegate to super().freeze_with(client) after ID generation

Task 6: Implement execute and execute_all

Add the multi-chunk execution flow that iterates through all chunks.

• Implement execute() that delegates to execute_all() and returns only the first response (matching existing behavior)
• Implement execute_all() with the re-freeze loop pattern: validate chunking, iterate chunks, clear _transaction_body_bytes and _signature_map, swap transaction ID, re-freeze, replay signatures, execute
• Include proper @overload decorators for type narrowing based on wait_for_receipt parameter
• Handle single-chunk optimization (delegate directly to super().execute() when only one chunk)

Task 7: Implement sign override

Centralize the signature key storage and signing logic.

• Override sign(private_key) to store the key in _signing_keys (with deduplication check)
• Delegate to super().sign(private_key) to sign the current frozen body
• Return self for method chaining

Task 8: Implement body_size_all_chunks property

Add the property that calculates serialized body sizes for all chunks.

• Implement body_size_all_chunks as a @property returning list[int]
• Require frozen state via _require_frozen()
• Iterate through _transaction_ids, temporarily setting _current_chunk_index and transaction_id for each
• Read self.body_size for each chunk and collect results
• Use try/finally to guarantee state restoration

🤖 Prompt for AI agents

Create a new file `src/hiero_sdk_python/transaction/chunked_transaction.py` that
defines the abstract `ChunkedTransaction(Transaction, ABC)` base class. This
phase establishes the entire shared chunking infrastructure used by both
`TopicMessageSubmitTransaction` and `FileAppendTransaction`.

- Import from `typing`, `abc`, and relevant internal modules
- In `__init__`, initialize: `_current_chunk_index`, `_transaction_ids`,
`_signing_keys`, `_initial_transaction_id` with appropriate defaults. Do NOT
initialize `chunk_size` or `max_chunks` — subclasses define their own defaults
- Define `@abstractmethod get_required_chunks() -> int` with a docstring noting
subclasses must return the number of chunks needed for their content
- Implement `set_chunk_size(chunk_size: int)` and `set_max_chunks(max_chunks:
int)`, each with a `_require_not_frozen()` guard, positive value validation, and
`return self` for chaining
- Implement `_validate_chunking()` comparing `get_required_chunks()` against
`max_chunks`, raising `ValueError` with a generic message when exceeded
- Override `freeze_with(client)` with an idempotent guard (early return if
`_transaction_body_bytes` is non-empty), then resolve the base transaction ID
via `_resolve_transaction_id(client)`, generate per-chunk transaction IDs using
nanosecond-staggered timestamps (chunk 0 reuses base ID; subsequent chunks
increment nanos with overflow handling), set `_initial_transaction_id` to chunk
0's ID, then call `super().freeze_with(client)`
- Implement `execute()` to delegate to `execute_all()` and return the first
response; implement `execute_all()` with the re-freeze loop pattern (validate
chunking, iterate chunks, clear `_transaction_body_bytes` and `_signature_map`,
swap transaction ID, re-freeze, replay signatures, execute); include `@overload`
decorators for type narrowing on `wait_for_receipt`; add single-chunk
optimization that delegates directly to `super().execute()`
- Override `sign(private_key)` to store the key in `_signing_keys` with a
deduplication check, then call `super().sign(private_key)`, returning `self`
- Implement `body_size_all_chunks` as a `@property` returning `list[int]`: call
`_require_frozen()`, iterate through `_transaction_ids` temporarily setting
`_current_chunk_index` and `transaction_id`, read `self.body_size` per chunk,
and use try/finally to guarantee state restoration

Phase 2: Refactor Existing Chunked Transactions

Update both concrete transaction classes to inherit from ChunkedTransaction, removing duplicated code while preserving transaction-specific behavior.

Task 1: Refactor TopicMessageSubmitTransaction

Update the class to inherit from ChunkedTransaction and remove all duplicated chunking logic.

• Change parent class from Transaction to ChunkedTransaction in src/hiero_sdk_python/consensus/topic_message_submit_transaction.py
• Remove fields now provided by base class: _current_chunk_index, _transaction_ids, _signing_keys, _initial_transaction_id
• Keep topic-specific fields: topic_id, message, custom_fee_limits
• Initialize chunk_size (default 1024) and max_chunks (default 20) in __init__
• Call super().__init__() to initialize base class state

Task 2: Remove duplicated methods from TopicMessageSubmitTransaction

Remove methods now provided by ChunkedTransaction base class.

• Remove freeze_with() override (base class handles ID generation)
• Remove execute() and execute_all() overrides
• Remove sign() override
• Remove body_size_all_chunks property
• Remove _validate_chunking() method
• Remove set_chunk_size() and set_max_chunks() methods (inherited from base)

Task 3: Preserve TopicMessageSubmitTransaction-specific behavior

Ensure topic-specific methods and proto building remain intact.

• Keep get_required_chunks() implementation (calculates based on message byte length and chunk_size)
• Keep _build_proto_body() with ConsensusMessageChunkInfo embedding (uses _initial_transaction_id from base)
• Keep build_transaction_body(), build_scheduled_body(), _get_method()
• Keep all topic-specific setters: set_topic_id(), set_message(), custom fee methods
• Update set_message() to no longer recalculate _total_chunks (field removed)

Task 4: Refactor FileAppendTransaction

Update the class to inherit from ChunkedTransaction and remove all duplicated chunking logic.

• Change parent class from Transaction to ChunkedTransaction in src/hiero_sdk_python/file/file_append_transaction.py
• Remove fields now provided by base class: _current_chunk_index, _transaction_ids, _signing_keys
• Keep file-specific fields: file_id, contents
• Initialize chunk_size (default 4096) and max_chunks (default 20) in __init__
• Call super().__init__() to initialize base class state

Task 5: Remove duplicated methods from FileAppendTransaction

Remove methods now provided by ChunkedTransaction base class.

• Remove freeze_with() override
• Remove execute() and execute_all() overrides
• Remove sign() override
• Remove body_size_all_chunks property
• Remove _validate_chunking() method
• Remove set_chunk_size() and set_max_chunks() methods (inherited from base)
• Remove _calculate_total_chunks() helper (replaced by get_required_chunks())

Task 6: Preserve FileAppendTransaction-specific behavior

Ensure file-specific methods and proto building remain intact.

• Keep get_required_chunks() implementation (calculates based on contents byte length and chunk_size)
• Keep _build_proto_body() without chunk metadata (file append has no cross-chunk linking)
• Keep build_transaction_body(), build_scheduled_body(), _get_method(), _from_protobuf()
• Keep all file-specific setters: set_file_id(), set_contents()
• Keep _encode_contents() helper for string-to-bytes conversion

🤖 Prompt for AI agents

Refactor both
`src/hiero_sdk_python/consensus/topic_message_submit_transaction.py` and
`src/hiero_sdk_python/file/file_append_transaction.py` to inherit from
`ChunkedTransaction` instead of `Transaction`, removing all logic now provided
by the base class.

**TopicMessageSubmitTransaction**
(`src/hiero_sdk_python/consensus/topic_message_submit_transaction.py`):
- Update the import to include `ChunkedTransaction` and change the parent class
declaration accordingly
- In `__init__`, call `super().__init__()`, remove `_current_chunk_index`,
`_transaction_ids`, `_signing_keys`, `_initial_transaction_id` field
initializations, keep topic-specific fields (`topic_id`, `message`,
`custom_fee_limits`), and set `chunk_size = 1024` and `max_chunks = 20`
- Delete the following methods entirely (now inherited): `freeze_with()`,
`execute()`, `execute_all()`, `sign()`, `body_size_all_chunks`,
`_validate_chunking()`, `set_chunk_size()`, `set_max_chunks()`
- Retain `get_required_chunks()` (calculates from message byte length and
`chunk_size`)
- Retain `_build_proto_body()` with `ConsensusMessageChunkInfo` embedding (it
may reference `_initial_transaction_id` from the base class — leave that
reference intact)
- Retain `build_transaction_body()`, `build_scheduled_body()`, `_get_method()`,
and all topic-specific setters
- In `set_message()`, remove any recalculation of `_total_chunks` since that
field is no longer present

**FileAppendTransaction**
(`src/hiero_sdk_python/file/file_append_transaction.py`):
- Update the import to include `ChunkedTransaction` and change the parent class
declaration accordingly
- In `__init__`, call `super().__init__()`, remove `_current_chunk_index`,
`_transaction_ids`, `_signing_keys` field initializations, keep file-specific
fields (`file_id`, `contents`), and set `chunk_size = 4096` and `max_chunks =
20`
- Delete the following methods entirely (now inherited): `freeze_with()`,
`execute()`, `execute_all()`, `sign()`, `body_size_all_chunks`,
`_validate_chunking()`, `set_chunk_size()`, `set_max_chunks()`,
`_calculate_total_chunks()`
- Retain `get_required_chunks()` (calculates from contents byte length and
`chunk_size`)
- Retain `_build_proto_body()` without any chunk linking metadata
- Retain `build_transaction_body()`, `build_scheduled_body()`, `_get_method()`,
`_from_protobuf()`, `set_file_id()`, `set_contents()`, and `_encode_contents()`

Phase 3: Package Integration

Register the new base class in the package exports to make it available to SDK users.

Export ChunkedTransaction

Add the new class to the package's public API.

• Add import statement in src/hiero_sdk_python/__init__.py: from .transaction.chunked_transaction import ChunkedTransaction
• Add "ChunkedTransaction" to the __all__ list in the transaction section
• Follow existing import ordering conventions in the file

🤖 Prompt for AI agents

Update `src/hiero_sdk_python/__init__.py` to expose `ChunkedTransaction` as part
of the public API.

- Add `from .transaction.chunked_transaction import ChunkedTransaction`
following the existing import ordering conventions in the file
- Add `"ChunkedTransaction"` to the `__all__` list, placed within the
transaction section consistent with how other transaction types are grouped

Research

The codebase follows a clear inheritance hierarchy: _Executable → Transaction → concrete transaction types. Both TopicMessageSubmitTransaction (consensus/) and FileAppendTransaction (file/) independently implement nearly identical chunking logic including fields (_current_chunk_index, _transaction_ids, _signing_keys, chunk_size, max_chunks) and methods (freeze_with, execute, execute_all, sign, body_size_all_chunks, _validate_chunking). The transaction package __init__.py is empty, and all public exports are registered in the top-level src/hiero_sdk_python/__init__.py. The primary structural difference between the two chunked transactions is that TopicMessageSubmitTransaction embeds ConsensusMessageChunkInfo metadata (using _initial_transaction_id) while FileAppendTransaction does not.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Create a new file `src/hiero_sdk_python/transaction/chunked_transaction.py` that
defines the abstract `ChunkedTransaction(Transaction, ABC)` base class. This
phase establishes the entire shared chunking infrastructure used by both
`TopicMessageSubmitTransaction` and `FileAppendTransaction`.

- Import from `typing`, `abc`, and relevant internal modules
- In `__init__`, initialize: `_current_chunk_index`, `_transaction_ids`,
`_signing_keys`, `_initial_transaction_id` with appropriate defaults. Do NOT
initialize `chunk_size` or `max_chunks` — subclasses define their own defaults
- Define `@abstractmethod get_required_chunks() -> int` with a docstring noting
subclasses must return the number of chunks needed for their content
- Implement `set_chunk_size(chunk_size: int)` and `set_max_chunks(max_chunks:
int)`, each with a `_require_not_frozen()` guard, positive value validation, and
`return self` for chaining
- Implement `_validate_chunking()` comparing `get_required_chunks()` against
`max_chunks`, raising `ValueError` with a generic message when exceeded
- Override `freeze_with(client)` with an idempotent guard (early return if
`_transaction_body_bytes` is non-empty), then resolve the base transaction ID
via `_resolve_transaction_id(client)`, generate per-chunk transaction IDs using
nanosecond-staggered timestamps (chunk 0 reuses base ID; subsequent chunks
increment nanos with overflow handling), set `_initial_transaction_id` to chunk
0's ID, then call `super().freeze_with(client)`
- Implement `execute()` to delegate to `execute_all()` and return the first
response; implement `execute_all()` with the re-freeze loop pattern (validate
chunking, iterate chunks, clear `_transaction_body_bytes` and `_signature_map`,
swap transaction ID, re-freeze, replay signatures, execute); include `@overload`
decorators for type narrowing on `wait_for_receipt`; add single-chunk
optimization that delegates directly to `super().execute()`
- Override `sign(private_key)` to store the key in `_signing_keys` with a
deduplication check, then call `super().sign(private_key)`, returning `self`
- Implement `body_size_all_chunks` as a `@property` returning `list[int]`: call
`_require_frozen()`, iterate through `_transaction_ids` temporarily setting
`_current_chunk_index` and `transaction_id`, read `self.body_size` per chunk,
and use try/finally to guarantee state restoration
===============================================================================

Task: 2

Refactor both
`src/hiero_sdk_python/consensus/topic_message_submit_transaction.py` and
`src/hiero_sdk_python/file/file_append_transaction.py` to inherit from
`ChunkedTransaction` instead of `Transaction`, removing all logic now provided
by the base class.

**TopicMessageSubmitTransaction**
(`src/hiero_sdk_python/consensus/topic_message_submit_transaction.py`):
- Update the import to include `ChunkedTransaction` and change the parent class
declaration accordingly
- In `__init__`, call `super().__init__()`, remove `_current_chunk_index`,
`_transaction_ids`, `_signing_keys`, `_initial_transaction_id` field
initializations, keep topic-specific fields (`topic_id`, `message`,
`custom_fee_limits`), and set `chunk_size = 1024` and `max_chunks = 20`
- Delete the following methods entirely (now inherited): `freeze_with()`,
`execute()`, `execute_all()`, `sign()`, `body_size_all_chunks`,
`_validate_chunking()`, `set_chunk_size()`, `set_max_chunks()`
- Retain `get_required_chunks()` (calculates from message byte length and
`chunk_size`)
- Retain `_build_proto_body()` with `ConsensusMessageChunkInfo` embedding (it
may reference `_initial_transaction_id` from the base class — leave that
reference intact)
- Retain `build_transaction_body()`, `build_scheduled_body()`, `_get_method()`,
and all topic-specific setters
- In `set_message()`, remove any recalculation of `_total_chunks` since that
field is no longer present

**FileAppendTransaction**
(`src/hiero_sdk_python/file/file_append_transaction.py`):
- Update the import to include `ChunkedTransaction` and change the parent class
declaration accordingly
- In `__init__`, call `super().__init__()`, remove `_current_chunk_index`,
`_transaction_ids`, `_signing_keys` field initializations, keep file-specific
fields (`file_id`, `contents`), and set `chunk_size = 4096` and `max_chunks =
20`
- Delete the following methods entirely (now inherited): `freeze_with()`,
`execute()`, `execute_all()`, `sign()`, `body_size_all_chunks`,
`_validate_chunking()`, `set_chunk_size()`, `set_max_chunks()`,
`_calculate_total_chunks()`
- Retain `get_required_chunks()` (calculates from contents byte length and
`chunk_size`)
- Retain `_build_proto_body()` without any chunk linking metadata
- Retain `build_transaction_body()`, `build_scheduled_body()`, `_get_method()`,
`_from_protobuf()`, `set_file_id()`, `set_contents()`, and `_encode_contents()`
===============================================================================

Task: 3

Update `src/hiero_sdk_python/__init__.py` to expose `ChunkedTransaction` as part
of the public API.

- Add `from .transaction.chunked_transaction import ChunkedTransaction`
following the existing import ordering conventions in the file
- Add `"ChunkedTransaction"` to the `__all__` list, placed within the
transaction section consistent with how other transaction types are grouped

💡 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!

[github-actions]

Hi @MonaaEid 👋

This issue has been assigned but no pull request has been created yet.
Are you still planning on working on it?
If you are, please create a draft PR linked to this issue or comment /working to let us know.
If you’re no longer able to work on this issue, you can comment /unassign to release it.

From the Python SDK Team

[MonaaEid]

/working

[github-actions]

Hi @MonaaEid, this is CronInactivityBot 👋

You were assigned to this issue 32 days ago, and there is currently no open pull request linked to it.
To keep the backlog available for active contributors, I'm unassigning you for now.

If you're no longer interested, no action is needed.

Tip: You can comment /unassign on any issue to proactively step away before this bot kicks in.

If you'd like to continue working on this later, feel free to comment /assign on the issue to get re-assigned, and open a new PR when you're ready. 🚀