feat(tck): implement updateTopic JSON-RPC method

[exploreriii]

Problem updateTopic is missing; the driver's TopicUpdateTransaction suites cannot run. It is the only topic-service method not yet implemented.

Solution Mirror the existing createTopic handler's param handling (memo, adminKey, submitKey, autoRenewPeriod, autoRenewAccountId, expirationTime, and the fee fields if the spec includes them) with topicId added.

Spec: https://github.com/hiero-ledger/hiero-sdk-tck/blob/main/docs/test-specifications/topic-service/TopicUpdateTransaction.md
JS reference: https://github.com/hiero-ledger/hiero-sdk-js/blob/main/tck/methods/topic.ts (updateTopic)
SDK class: TopicUpdateTransaction
Same set-only-present-fields rule as updateToken.

[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 updateTopic as a thin vertical slice: a new UpdateTopicParams model, a status-only UpdateTopicResponse model, and an @rpc_method("updateTopic") handler backed by the SDK's TopicUpdateTransaction.
• Mirror createTopic's field handling (memo, keys, auto-renew, fee fields, custom fees) plus topicId and expirationTime, reusing existing param-parsing helpers and the module-local _build_custom_fee helper.
• Apply the "set-only-present-fields" rule (each field set only when not None), matching the existing update_account handler pattern; no routing/registry changes are required due to decorator-based auto-registration.
• Add handler-level unit tests under tests/tck/ following the existing mock-client conventions to support the driver's TopicUpdateTransaction suites.

Implementation Steps

Phase 1: Add updateTopic request/response models and handler

This phase delivers the full updateTopic JSON-RPC method by introducing its params model, its response model, and the handler that ties them to the SDK's TopicUpdateTransaction. These changes are grouped together because they form a single cohesive vertical slice — the handler cannot function without its params/response types, and the registry auto-wires the new method as soon as the decorated handler is imported (already covered by tck/handlers/__init__.py).

Task 1: Define the `UpdateTopicParams` request model

Introduce a params dataclass mirroring CreateTopicParams with topicId and expirationTime added, following the established parsing conventions.

• Add an UpdateTopicParams dataclass to tck/param/topic.py, extending BaseTransactionParams so it inherits sessionId and commonTransactionParams.
• Include fields: topicId, memo, adminKey, submitKey, autoRenewPeriod, autoRenewAccountId, expirationTime, feeScheduleKey, feeExemptKeys, customFees (mirroring CreateTopicParams plus topicId from TopicMessageSubmitParams and expirationTime modeled after UpdateAccountParams).
• Add a parse_json_params classmethod that reuses the existing coercion helpers from tck/util/param_utils.py (to_int for autoRenewPeriod/expirationTime, non_empty_string_or_none for key/account fields, non_empty_string_list for feeExemptKeys, parse_session_id, parse_common_transaction_params), parsing topicId via params.get("topicId") to match the existing topicId naming convention.
• Reuse the same list-validation guards for feeExemptKeys and customFees that CreateTopicParams already performs, including delegating to CustomFeeParams.parse_json_params.

Task 2: Define the `UpdateTopicResponse` model

Add a status-only response model consistent with other update/mutation handlers.

• Add an UpdateTopicResponse dataclass to tck/response/topic.py with a single status: str | None field, mirroring UpdateAccountResponse and TopicMessageSubmitResponse.

Task 3: Implement the `updateTopic` handler and transaction builder

Add the handler that builds and executes a TopicUpdateTransaction, setting only provided fields.

• Add a private _build_update_topic_transaction() helper to tck/handlers/topic.py that constructs a TopicUpdateTransaction with the default gRPC deadline, then conditionally applies each field only when it is not None, following the "set-only-present-fields" rule used by _build_update_account_transaction.
• Set topicId via TopicId.from_string(params.topicId) (already imported and used in this module) and expirationTime via Timestamp(params.expirationTime, 0) (mirroring the account update pattern).
• Reuse the existing module-local _build_custom_fee helper for customFees, and reuse get_key_from_string for adminKey/submitKey/feeScheduleKey/feeExemptKeys, and AccountId.from_string for autoRenewAccountId — exactly as createTopic does.
• Add an update_topic() function decorated with @rpc_method("updateTopic") that obtains the client via get_client(params.sessionId), builds the transaction, applies commonTransactionParams when present, executes with wait_for_receipt=False, retrieves the receipt with validate_status=True, and returns UpdateTopicResponse populated with ResponseCode(receipt.status).name.
• Import the new UpdateTopicParams and UpdateTopicResponse at the top of tck/handlers/topic.py; no changes to registry.py, server.py, protocol.py, or tck/handlers/__init__.py are needed since topic is already imported and the decorator auto-registers the method.

🤖 Prompt for AI agents

Implement the full `updateTopic` JSON-RPC method as a vertical slice: params
model, response model, and handler.

1. In `tck/param/topic.py`, add an `UpdateTopicParams` dataclass extending
`BaseTransactionParams` (inherits `sessionId` and `commonTransactionParams`).
Include fields: `topicId`, `memo`, `adminKey`, `submitKey`, `autoRenewPeriod`,
`autoRenewAccountId`, `expirationTime`, `feeScheduleKey`, `feeExemptKeys`,
`customFees`, mirroring `CreateTopicParams` with `topicId` (from
`TopicMessageSubmitParams`) and `expirationTime` (modeled after
`UpdateAccountParams`) added.
- Add a `parse_json_params` classmethod using existing helpers from
`tck/util/param_utils.py`: `to_int` for `autoRenewPeriod`/`expirationTime`,
`non_empty_string_or_none` for key/account fields, `non_empty_string_list` for
`feeExemptKeys`, `parse_session_id`, and `parse_common_transaction_params`.
Parse `topicId` via `params.get("topicId")`.
- Reuse the same list-validation guards for `feeExemptKeys` and `customFees` as
`CreateTopicParams`, including delegating to
`CustomFeeParams.parse_json_params`.

2. In `tck/response/topic.py`, add an `UpdateTopicResponse` dataclass with a
single `status: str | None` field, mirroring `UpdateAccountResponse` and
`TopicMessageSubmitResponse`.

3. In `tck/handlers/topic.py`:
   - Import the new `UpdateTopicParams` and `UpdateTopicResponse`.
- Add a private `_build_update_topic_transaction()` helper that constructs a
`TopicUpdateTransaction` with the default gRPC deadline, then conditionally sets
each field only when not `None` (the "set-only-present-fields" rule, matching
`_build_update_account_transaction`).
- Set `topicId` via `TopicId.from_string(params.topicId)` and `expirationTime`
via `Timestamp(params.expirationTime, 0)`.
- Reuse the module-local `_build_custom_fee` helper for `customFees`,
`get_key_from_string` for
`adminKey`/`submitKey`/`feeScheduleKey`/`feeExemptKeys`, and
`AccountId.from_string` for `autoRenewAccountId`, exactly as `createTopic` does.
- Add an `update_topic()` function decorated with `@rpc_method("updateTopic")`
that: obtains the client via `get_client(params.sessionId)`, builds the
transaction via the helper, applies `commonTransactionParams` when present,
executes with `wait_for_receipt=False`, retrieves the receipt with
`validate_status=True`, and returns an `UpdateTopicResponse` populated with
`ResponseCode(receipt.status).name`.
- No changes needed to `registry.py`, `server.py`, `protocol.py`, or
`tck/handlers/__init__.py` since the decorator auto-registers the method once
the module is imported.

Phase 2: Add unit test coverage for the updateTopic handler

Establish direct test coverage for the new handler following the existing TCK test conventions, since the driver's TopicUpdateTransaction suites depend on this method.

Add handler-level tests for updateTopic

Create tests that validate params parsing and transaction building using the established mock-client pattern.

• Add a new test file under tests/tck/ (using the repo's *_test.py suffix convention, e.g. tests/tck/topic_test.py) covering UpdateTopicParams.parse_json_params and _build_update_topic_transaction.
• Follow the MagicMock(spec=Client) + real-transaction style demonstrated in tests/tck/common_params_test.py to verify that provided fields are set on the TopicUpdateTransaction and omitted fields are left untouched (the "set-only-present-fields" behavior), including topicId and expirationTime handling.
• Optionally verify registry wiring by confirming updateTopic resolves through the dispatch mechanism, consistent with tests/tck/handlers_test.py.

🤖 Prompt for AI agents

Add unit test coverage for the new `updateTopic` handler following existing TCK
test conventions.

1. Create a new test file under `tests/tck/` using the repo's `*_test.py` suffix
convention (e.g. `tests/tck/topic_test.py`).
2. Cover `UpdateTopicParams.parse_json_params` and
`_build_update_topic_transaction`.
3. Follow the `MagicMock(spec=Client)` + real-transaction style demonstrated in
`tests/tck/common_params_test.py` to verify that provided fields are correctly
set on the `TopicUpdateTransaction` and that omitted fields remain untouched
(the "set-only-present-fields" behavior), including specific coverage for
`topicId` and `expirationTime` handling.
4. Optionally, verify registry wiring by confirming `updateTopic` resolves
correctly through the dispatch mechanism, consistent with the pattern in
`tests/tck/handlers_test.py`.

Research

The TCK layer lives under tck/ and exposes SDK functionality via JSON-RPC. Handlers are registered by name through the @rpc_method(...) decorator in tck/handlers/registry.py, which auto-populates a global handler registry when handler modules are imported by tck/handlers/__init__.py. Each handler consumes a typed params dataclass (from tck/param/) parsed via parse_json_params, builds an SDK transaction, applies common transaction params, executes it, and returns a response dataclass (from tck/response/) whose None fields are stripped during serialization. Topic support currently exists for createTopic, submitTopicMessage, and getTopicInfo in tck/handlers/topic.py, but updateTopic is absent. The closest existing "update" analog is update_account in tck/handlers/account.py. The SDK's TopicUpdateTransaction (src/hiero_sdk_python/consensus/topic_update_transaction.py) exposes setters for all relevant fields plus topicId and expirationTime. No changes are required to routing, dispatch, or registry infrastructure — the decorator mechanism handles registration automatically.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the full `updateTopic` JSON-RPC method as a vertical slice: params
model, response model, and handler.

1. In `tck/param/topic.py`, add an `UpdateTopicParams` dataclass extending
`BaseTransactionParams` (inherits `sessionId` and `commonTransactionParams`).
Include fields: `topicId`, `memo`, `adminKey`, `submitKey`, `autoRenewPeriod`,
`autoRenewAccountId`, `expirationTime`, `feeScheduleKey`, `feeExemptKeys`,
`customFees`, mirroring `CreateTopicParams` with `topicId` (from
`TopicMessageSubmitParams`) and `expirationTime` (modeled after
`UpdateAccountParams`) added.
- Add a `parse_json_params` classmethod using existing helpers from
`tck/util/param_utils.py`: `to_int` for `autoRenewPeriod`/`expirationTime`,
`non_empty_string_or_none` for key/account fields, `non_empty_string_list` for
`feeExemptKeys`, `parse_session_id`, and `parse_common_transaction_params`.
Parse `topicId` via `params.get("topicId")`.
- Reuse the same list-validation guards for `feeExemptKeys` and `customFees` as
`CreateTopicParams`, including delegating to
`CustomFeeParams.parse_json_params`.

2. In `tck/response/topic.py`, add an `UpdateTopicResponse` dataclass with a
single `status: str | None` field, mirroring `UpdateAccountResponse` and
`TopicMessageSubmitResponse`.

3. In `tck/handlers/topic.py`:
   - Import the new `UpdateTopicParams` and `UpdateTopicResponse`.
- Add a private `_build_update_topic_transaction()` helper that constructs a
`TopicUpdateTransaction` with the default gRPC deadline, then conditionally sets
each field only when not `None` (the "set-only-present-fields" rule, matching
`_build_update_account_transaction`).
- Set `topicId` via `TopicId.from_string(params.topicId)` and `expirationTime`
via `Timestamp(params.expirationTime, 0)`.
- Reuse the module-local `_build_custom_fee` helper for `customFees`,
`get_key_from_string` for
`adminKey`/`submitKey`/`feeScheduleKey`/`feeExemptKeys`, and
`AccountId.from_string` for `autoRenewAccountId`, exactly as `createTopic` does.
- Add an `update_topic()` function decorated with `@rpc_method("updateTopic")`
that: obtains the client via `get_client(params.sessionId)`, builds the
transaction via the helper, applies `commonTransactionParams` when present,
executes with `wait_for_receipt=False`, retrieves the receipt with
`validate_status=True`, and returns an `UpdateTopicResponse` populated with
`ResponseCode(receipt.status).name`.
- No changes needed to `registry.py`, `server.py`, `protocol.py`, or
`tck/handlers/__init__.py` since the decorator auto-registers the method once
the module is imported.
===============================================================================

Task: 2

Add unit test coverage for the new `updateTopic` handler following existing TCK
test conventions.

1. Create a new test file under `tests/tck/` using the repo's `*_test.py` suffix
convention (e.g. `tests/tck/topic_test.py`).
2. Cover `UpdateTopicParams.parse_json_params` and
`_build_update_topic_transaction`.
3. Follow the `MagicMock(spec=Client)` + real-transaction style demonstrated in
`tests/tck/common_params_test.py` to verify that provided fields are correctly
set on the `TopicUpdateTransaction` and that omitted fields remain untouched
(the "set-only-present-fields" behavior), including specific coverage for
`topicId` and `expirationTime` handling.
4. Optionally, verify registry wiring by confirming `updateTopic` resolves
correctly through the dispatch mechanism, consistent with the pattern in
`tests/tck/handlers_test.py`.

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

[achintya2k5]

/assign

[github-actions]

👋 Hi @achintya2k5! Thanks for your interest in contributing 💡

Before taking on a beginner issue, we ask contributors to complete at least one Good First Issue to get familiar with the workflow.

👉 Find a Good First Issue here

Please try a GFI first, then come back — we’ll be happy to assign this! 😊