Add `clear_custom_fee_limits()` to TopicMessageSubmitTransaction

[manishdait]

🧑‍🎓 Beginner Issue

Welcome! This is a Beginner Issue designed to help you learn the codebase.

🏁 When this issue is complete, you will have:

✅ Researched a file or method in detail
✅ Followed SDK patterns to implement a solution
✅ Researched and identified appropriate programming constructs to solve the problem
✅ Created basic tests
✅ Delivered a clean, review-ready pull request

🐞 Problem Description

TopicMessageSubmitTransaction currently allows custom fee limits to be configured and appended through set_custom_fee_limits() and add_custom_fee_limit(). However, there is no method to remove previously configured fee limits.

Other SDKs exposes a clearCustomFeeLimits() method that clears all configured fee limits before the transaction is executed For Reference. Adding the same capability to the Python SDK would improve API consistency and make it easier for developers to update a transaction without recreating it.

💡 Expected Solution

Introduce a clear_custom_fee_limits() method on TopicMessageSubmitTransaction that removes all configured custom fee limits.

🔍 Research Pointers

• Inspect hiero_sdk_python/topic/topic_message_submit_transaction.py to understand how custom fee limits are currently managed.
• Review the other SDKs implementation of clearCustomFeeLimits() to understand the expected behavior.
• Update the existing topic message submit transaction tests to cover the new API.

🛠️ Implementation Notes

• Add a clear_custom_fee_limits() method to TopicMessageSubmitTransaction.
• Ensure the transaction cannot be modified after it has been frozen.
• Sould return self to preserve method chaining.
• Add tests covering the changes.

🧠 Beginner Contributors — Prerequisites & Expectations

Caution

Beginner issues are low-risk but we expect a working solution.

Important

We recommend completing at least 3 Good First Issues before attempting a beginner issue.

Difficulty:

• Requires building knowledge of the specific file(s)
• Beginner to intermediate Coding skills

Tip

You should be comfortable with:

• Forking, branching, committing (with DCO + GPG signing), and opening a pull request without a tutorial
• Reading beginner to intermediate code you did not write and following its patterns
• Handling simple merge conflicts
• Keeping your fork up to date with main by rebasing
• Looking things up on your own before asking for help

If any of that feels unfamiliar, Good First Issues might still be the most rewarding path for you right now — find one here.
You can always come back when you are ready.

⚠️ AI Usage Policy

• AI can help you understand the codebase and the problem
• Using AI to generate code for beginner issues is strictly discouraged
• Using AI as the main source of research is strictly discouraged, refer to language and library documentation, protobuf definitions and other SDKs.

⏱️ Timeline & Workflow

• Typical time: ~1 Week / ~8 hours.
  🧩 Difficulty: Manageable but requires investigation and testing
  🎓 Best for: Beginner contributors

• 🔴 Completing a beginner issue in 1–3 hours is a red flag.

Tip

Suggested: share your proposed implementation approach as a comment before writing code to get early feedback and avoid wasted effort.

🧪 Testing Requirements

Important

At the beginner level, testing will be necessary but a small component.
The methods you implement should be verified (happy path at least)

How you test depends on the type of change.

Source code changes (e.g. in src/):

• Write basic unit tests
• Run tests locally: uv run pytest tests/unit/<specific_file>_test.py -v
• Integration tests will run automatically when you push

GitHub Actions / workflow changes (e.g. in .github/): Guide

• Test by merging to your fork's main and simulating the scenario

Example script changes (e.g. in examples/):

• Run the example script and confirm output matches expected behavior
• You will need a Hedera Portal account for testnet credentials

🛡️ Quality & Review Standards

Beginner PRs must be working and follow best practices.

1. Working: The implementation must solve the problem and meet the acceptance criteria.
2. SDK Best Practices: The solution should fit well with existing SDK patterns and abstractions.
3. Testing: basic unit and possibly integration tests to demonstrate the implementation works as expected.

⚠️ Breaking changes

• Watch for any changes that could impact existing users, even if they seem small.

🤖 AI notes

• AI has gaps or incorrect understanding of repo-specific patterns, logic, and protobuf schemes.

✅ PR Quality Checklist

Before opening your PR, confirm:

• I have spent the majority of my time researching the problem and building my understanding of the codebase and methods.
• My implementation works and is tested (if applicable).
• Every line of code is personally understood and explainable.
• My changes address what the issue asked for — nothing more, nothing less
• I have applied appropriate linting, code quality, and formatting tools used in this repo.

Before requesting a review, confirm:

• I did not modify files unrelated to this issue
• Clean git history — no rebase artifacts, merge commits, or unrelated files
• My commits are signed: git commit -S -s -m "chore: description" — Signing guide
• I have included appropriate tests and all CI checks pass.

📋 Workflow quick reference

You have done this before — here are the links if you need them:

Step	Guide
Claim this issue	Comment /assign below
Sync with main	Rebasing guide
Open a PR and link this issue	PR guide
Resolve merge conflicts	Merge conflicts guide

📚 Resources & Support

🆘 Stuck?

Tip

Comment on this issue: and describe what you have tried. A maintainer will respond.

Python SDK References:

• Windows Setup Guide — platform-specific installation steps
• Pylance guide — inline type checking during development
• Running examples
• Browse closed beginner PRs — see how others did it

References:

• Hedera Protobufs
• Community Calls
• Discord

[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

• Add a single clear_custom_fee_limits() method to TopicMessageSubmitTransaction that reuses the existing _require_not_frozen() guard, resets the inherited custom_fee_limits list, and returns self.
• Mirror the fluent-builder and docstring conventions already used by set_custom_fee_limits()/add_custom_fee_limit() for consistency.
• Extend the existing unit test file to cover happy-path clearing, method chaining, and frozen-state exception handling without adding new fixtures or scope.

Implementation Steps

Add the clear method and cover it with tests

This phase introduces the new API on the transaction class following the established fluent-builder and freeze-guard conventions, then extends the existing unit test suite to verify both happy-path and frozen-state behavior. Both tasks are grouped because the method and its tests form a single reviewable unit for this beginner-scoped change.

Task 1: Implement `clear_custom_fee_limits()` on TopicMessageSubmitTransaction

Add a method that empties the configured custom fee limits while adhering to existing SDK patterns.

• Add clear_custom_fee_limits() to src/hiero_sdk_python/consensus/topic_message_submit_transaction.py, placed alongside set_custom_fee_limits() and add_custom_fee_limit() for cohesion.
• Begin the method with self._require_not_frozen() to enforce immutability after freezing, matching every other setter in the class.
• Clear the inherited self.custom_fee_limits list (reset to an empty list) and return self, typed as TopicMessageSubmitTransaction, to preserve fluent chaining.
• Follow the existing Google-style docstring convention (with Returns: section) used by the neighboring setter methods.

Task 2: Extend unit tests to cover the new method

Verify the happy path, chainability, and frozen-transaction enforcement for the new method.

• Update tests/unit/topic_message_submit_transaction_test.py to assert that, after configuring fee limits, calling clear_custom_fee_limits() leaves custom_fee_limits empty and returns the transaction instance (confirming chainability).
• Add the new method to the frozen-state test (test_set_methods_require_not_frozen), adjusting the loop so it can invoke a zero-argument method and assert it raises Exception matching "Transaction is immutable; it has been frozen".
• Reuse the existing custom_fee_limit fixture and established assertion style (result is tx_default) rather than introducing new fixtures.

🤖 Prompt for AI agents

Implement a new `clear_custom_fee_limits()` method on
`TopicMessageSubmitTransaction` and add unit test coverage for it, following
existing SDK conventions.

1. In `src/hiero_sdk_python/consensus/topic_message_submit_transaction.py`, add
a `clear_custom_fee_limits()` method placed alongside `set_custom_fee_limits()`
and `add_custom_fee_limit()`.
- Start the method by calling `self._require_not_frozen()` to enforce the
frozen-transaction guard, matching the pattern used by every other setter in the
class.
   - Reset the inherited `self.custom_fee_limits` list to an empty list.
- Return `self`, typed as `TopicMessageSubmitTransaction`, to preserve fluent
method chaining.
- Add a Google-style docstring including a `Returns:` section, matching the
docstring style of the neighboring setter methods.

2. In `tests/unit/topic_message_submit_transaction_test.py`:
- Add/update a test to assert that after configuring fee limits, calling
`clear_custom_fee_limits()` results in an empty `custom_fee_limits` list and
that the method returns the transaction instance itself (verifying
chainability), using the assertion style `result is tx_default`.
- Update `test_set_methods_require_not_frozen` to include the new method in its
loop of frozen-state checks, adjusting the loop so it supports invoking a
zero-argument method, and assert that calling it on a frozen transaction raises
`Exception` matching `"Transaction is immutable; it has been frozen"`.
- Reuse the existing `custom_fee_limit` fixture rather than introducing new
fixtures.

Research

The Python SDK models consensus transactions under src/hiero_sdk_python/consensus/. TopicMessageSubmitTransaction (in consensus/topic_message_submit_transaction.py) extends ChunkedTransaction → Transaction. Custom fee limits are stored in the inherited self.custom_fee_limits: list[CustomFeeLimit] attribute (initialized in the base Transaction.__init__). The existing setters set_custom_fee_limits() and add_custom_fee_limit() follow a fluent-builder pattern: each calls self._require_not_frozen() first, mutates the list, then returns self. Freeze enforcement is centralized in Transaction._require_not_frozen(), which raises a plain Exception when the transaction body bytes have been populated. Unit tests live in tests/unit/topic_message_submit_transaction_test.py, following the <module>_test.py convention with pytestmark = pytest.mark.unit and dedicated tests for setter behavior, chaining, and frozen-state enforcement.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Implement a new `clear_custom_fee_limits()` method on
`TopicMessageSubmitTransaction` and add unit test coverage for it, following
existing SDK conventions.

1. In `src/hiero_sdk_python/consensus/topic_message_submit_transaction.py`, add
a `clear_custom_fee_limits()` method placed alongside `set_custom_fee_limits()`
and `add_custom_fee_limit()`.
- Start the method by calling `self._require_not_frozen()` to enforce the
frozen-transaction guard, matching the pattern used by every other setter in the
class.
   - Reset the inherited `self.custom_fee_limits` list to an empty list.
- Return `self`, typed as `TopicMessageSubmitTransaction`, to preserve fluent
method chaining.
- Add a Google-style docstring including a `Returns:` section, matching the
docstring style of the neighboring setter methods.

2. In `tests/unit/topic_message_submit_transaction_test.py`:
- Add/update a test to assert that after configuring fee limits, calling
`clear_custom_fee_limits()` results in an empty `custom_fee_limits` list and
that the method returns the transaction instance itself (verifying
chainability), using the assertion style `result is tx_default`.
- Update `test_set_methods_require_not_frozen` to include the new method in its
loop of frozen-state checks, adjusting the loop so it supports invoking a
zero-argument method, and assert that calling it on a frozen transaction raises
`Exception` matching `"Transaction is immutable; it has been frozen"`.
- Reuse the existing `custom_fee_limit` fixture rather than introducing new
fixtures.

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