Test

[aceppaluni]

Testing flow

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore tell me about this PR

[aceppaluni]

@learnmore Why was this change made?

[aceppaluni]

@learnmore Why was this change made?

[aceppaluni]

@learnmore Why was the FeeEstimateQuery added?

[aceppaluni]

@learnmore Why was FeeEstimateQuery added?

[codecoach-learning]

Why Was FeeEstimateQuery Added?

FeeEstimateQuery was added as part of the implementation of HIP-1261 (noted in the CHANGELOG.md entry: "Added an implementation for HIP-1261. (hiero-ledger#2019)").

What it does

It provides a way to estimate transaction fees before submitting a transaction to the network. Rather than executing a transaction blindly, developers can first query the Hedera Mirror Node REST API (/api/v1/network/fees) to get a cost breakdown.

The fee estimate breaks down into three components:

• Node fee – paid to the node that submits the transaction
• Service fee – paid for the network service
• Network fee – computed as node_fee × network_multiplier
• Total – the sum of all three

How it integrates

A convenience method estimate_fee() was added directly to the base Transaction class, allowing a fluent API like:

tx = TransferTransaction()
tx.add_hbar_transfer("0.0.1001", Hbar(-1))
tx.add_hbar_transfer("0.0.1002", Hbar(1))

result = tx.estimate_fee().set_mode(FeeEstimateMode.INTRINSIC).execute(client)
print(result.total)

Supported modes

Two estimation modes are supported via FeeEstimateMode:

• STATE (default) – estimates fees based on current network state
• INTRINSIC – estimates fees based on the transaction's intrinsic properties alone

Key behaviors

• Raises ValueError if no transaction is set before calling execute()
• Returns INVALID_ARGUMENT (ValueError) on HTTP 400 responses
• Retries automatically on transient errors like UNAVAILABLE or DEADLINE_EXCEEDED

[aceppaluni]

@learnmore what is the difference between add_hbar_transfer() and _add_hbar_transfer()

[codecoach-learning]

add_hbar_transfer() vs _add_hbar_transfer()

These two methods work together in a public/private pattern:

_add_hbar_transfer() — Internal/Private Method

def _add_hbar_transfer(self, account_id, amount, is_approved=False):

• Prefixed with _ to signal it's an internal implementation method (not part of the public API)
• Accepts a third parameter: is_approved: bool — controlling whether the transfer is an approved/delegated transfer
• Contains all the core validation and logic:
  • Checks the transaction isn't frozen
  • Accepts string account IDs and converts them via AccountId.from_string() (new in this PR)
  • Validates types for account_id and amount
  • Rejects zero amounts
  • Merges amounts if a transfer for the same account already exists
  • Appends a new HbarTransfer if no existing entry is found

add_hbar_transfer() — Public Method

def add_hbar_transfer(self, account_id, amount):

• The public-facing API that developers use directly
• Simply calls _add_hbar_transfer(account_id, amount, False) — hardcoding is_approved=False
• Returns self for method chaining

The Third Variant: add_approved_hbar_transfer()

There's also a third method that calls the same internal method with is_approved=True:

def add_approved_hbar_transfer(self, account_id, amount):
    self._add_hbar_transfer(account_id, amount, True)

Summary

Method	Public?	is_approved	Purpose
_add_hbar_transfer()	❌ Internal	Configurable	Core logic & validation
add_hbar_transfer()	✅ Yes	Always False	Standard transfer
add_approved_hbar_transfer()	✅ Yes	Always True	Delegated/approved transfer

The key change in this PR is that _add_hbar_transfer() now also accepts string account IDs (e.g., "0.0.1001") and converts them automatically, which is why the tests can do tx.add_hbar_transfer("0.0.1001", Hbar(-1)).

[aceppaluni]

@learnmore what was discussed about FeeEstimateQuery in this PR?

[codecoach-learning]

What Was Discussed About FeeEstimateQuery in This PR

Based on the PR conversation and code changes, here's a summary of what was covered:

In the Conversation

The user asked why FeeEstimateQuery was added, and the bot explained:

• It was added as part of HIP-1261 implementation
• It estimates transaction fees before submitting to the network by calling the Mirror Node REST API (/api/v1/network/fees)
• It supports two modes: STATE (default) and INTRINSIC
• A convenience method estimate_fee() was added to the base Transaction class

In the Code Changes

The actual implementation introduced in this PR includes:

File	Purpose
fee_estimate_query.py	Main query class with execute(), set_mode(), set_transaction()
fee_estimate.py	Dataclass holding base + extras, with a subtotal property
fee_estimate_response.py	Response dataclass with node_fee, service_fee, network_fee, total
fee_estimate_mode.py	FeeEstimateMode enum (STATE / INTRINSIC)
fee_extra.py / network_fee.py	Supporting dataclasses
transaction.py	Added estimate_fee() convenience method
test_fee_estimate_query.py	17 unit tests covering the new feature

Notable Implementation Details Visible in the Diff

• Commented-out freeze logic in set_transaction() — there was clearly some back-and-forth about whether to auto-freeze the transaction before estimating, but it was left commented out:

  #if hasattr(transaction, "freeze") and not transaction.is_frozen:
      #transaction.freeze()

• The actual transaction bytes sent to the API are hardcoded as b"dummy" — suggesting this is an incomplete/draft implementation
• The fee formula is: total = node_fee + service_fee + (node_fee × network_multiplier)

No Direct Discussion of FeeEstimateQuery in PR Comments

The conversation in this PR was entirely questions directed at the LearnMore bot — there were no human-to-human review comments discussing design decisions, tradeoffs, or concerns about FeeEstimateQuery specifically.

[aceppaluni]

@learnmore What is the main purpose of this PR?

[codecoach-learning]

Main Purpose of This PR

This PR has two primary goals:

1. 🆕 Implement FeeEstimateQuery (HIP-1261)

The core feature is a new FeeEstimateQuery class that lets developers estimate transaction fees before submitting a transaction to the Hedera network. It works by calling the Mirror Node REST API (/api/v1/network/fees) and returns a breakdown of:

• node_fee + service_fee + network_fee = total

A convenience method estimate_fee() was also added to the base Transaction class, enabling usage like:

result = TransferTransaction().estimate_fee().execute(client)

2. 🔧 Accept String Account IDs in TransferTransaction

A small but useful improvement in transfer_transaction.py — _add_hbar_transfer() now accepts string account IDs (e.g., "0.0.1001") and auto-converts them via AccountId.from_string(), rather than requiring callers to construct an AccountId object manually.

3. ⚙️ GitHub Automation

A new workflow (.github/workflows/generate-good-first-issue.yml) and script (.github/scripts/generate_issue.py) were added to automatically generate "good first issue" GitHub issues using OpenAI's API — though this is unrelated to the SDK functionality itself.

---

Note: The PR title ("Test") and description ("Testing flow") are minimal, but the actual code changes represent a substantive feature addition.

[aceppaluni]

@learnmore What is the goal of this PR?

[codecoach-learning]

Goal of This PR

Based on the code changes, this PR has two main goals:

1. 🆕 Implement FeeEstimateQuery (HIP-1261)

The primary feature is a new mechanism to estimate transaction fees before submitting a transaction to the Hedera network. Key files added:

• src/hiero_sdk_python/query/fee_estimate_query.py — The main query class that calls the Mirror Node REST API (/api/v1/network/fees) and returns a fee breakdown
• src/hiero_sdk_python/fees/ — Supporting dataclasses (FeeEstimate, FeeEstimateResponse, FeeEstimateMode, FeeExtra, NetworkFee)
• src/hiero_sdk_python/transaction/transaction.py — Added an estimate_fee() convenience method on the base Transaction class

This allows usage like:

result = TransferTransaction().estimate_fee().execute(client)
print(result.total)  # node_fee + service_fee + network_fee

2. 🔧 Accept String Account IDs in TransferTransaction

A small quality-of-life improvement in transfer_transaction.py — _add_hbar_transfer() now auto-converts string account IDs:

# Before: required AccountId object
# After: strings work too
tx.add_hbar_transfer("0.0.1001", Hbar(-1))

3. ⚙️ AI-Powered Issue Generation

Two files were added (.github/scripts/generate_issue.py and .github/workflows/generate-good-first-issue.yml) to automatically generate "good first issue" GitHub issues using OpenAI's API — unrelated to SDK functionality.

---

Note: The PR title ("Test") and description ("Testing flow") don't reflect the actual scope of changes, which represent a meaningful feature addition.