hiero-ledger / hiero-ledger/hiero-sdk-python

feat(tck): implement updateNode JSON-RPC method

Open
#2,597 10 comments 0 reactions 0 assignees View on GitHub
approved lang: python scope: TCK skill: intermediate
Dominant language
Python
Stars
63
Forks
298
Avg merge
3d 18h
Merged PRs (30d)
38

Description

**Problem**

The TCK server does not implement `updateNode`, so the TCK driver's `NodeUpdateTransaction` suite cannot run against the Python SDK. The SDK transaction already exists: `src/hiero_sdk_python/nodes/node_update_transaction.py` (`NodeUpdateTransaction`).

**Blocked by #2593 (`createNode`)** — it creates `tck/param/node.py` / `tck/handlers/node.py` and the `ServiceEndpoint` dataclass, and the update suite needs a node to update.

**Before you start — required reading**

TCK handlers are contract work: the TCK driver validates exact parameter names, optionality, defaults, and error semantics against the published spec. Please do not code from this issue title alone (or paste it into an AI tool and ship the first thing that runs) — read these first:

1. **The spec page linked below**, in full — especially the parameter table, the expected response shape, and the error/edge-case tests. If your handler's behavior differs from the spec table, the TCK suite will fail even if the happy path works.
2. [`tck/README.md`](https://github.com/hiero-ledger/hiero-sdk-python/blob/main/tck/README.md) — how the JSON-RPC server, param dataclasses, handler registry, and responses fit together, and how to run the TCK driver locally against your handler. Run the actual TCK suite before opening a PR; unit tests alone are not enough.
3. **An existing handler as your pattern** — pick the closest one in `tck/handlers/` with its matching `tck/param/` dataclass and follow its structure, naming, and error handling exactly. Do not invent a new style, and do not re-implement SDK logic in the handler — handlers only wire validated params onto the existing SDK transaction/query.
4. **The SDK class you are wrapping** (path in the Problem section) — read its setters and defaults so you know what the SDK already handles for you.
5. [`CONTRIBUTING.md`](https://github.com/hiero-ledger/hiero-sdk-python/blob/main/CONTRIBUTING.md) — test and PR conventions.

**Solution**

- [ ] Add an `UpdateNodeParams` dataclass to `tck/param/node.py` — same fields as create plus the required `nodeId`; check the spec table for which fields are updatable and how "unset" vs "absent" is distinguished.
- [ ] Add an `updateNode` handler to `tck/handlers/node.py` registered via `@rpc_method("updateNode")`, wrapping `NodeUpdateTransaction`. Only call a setter when the param is present — an update must not silently rewrite fields the caller didn't send (see how `updateToken` / `updateTopic` handlers handle partial updates).
- [ ] Add unit tests under `tests/tck/`, then run the TCK driver's NodeUpdateTransaction suite locally.

**Acceptance criteria**

- [ ] `updateNode` registered and dispatchable
- [ ] Partial updates only touch supplied fields
- [ ] Spec error cases behave as specified (missing/invalid `nodeId`, invalid endpoints/certificates, missing admin-key signature)
- [ ] Unit tests added and the TCK `NodeUpdateTransaction` suite passes

Spec: https://github.com/hiero-ledger/hiero-sdk-tck/blob/main/docs/test-specifications/node-service/NodeUpdateTransaction.md
JS reference: https://github.com/hiero-ledger/hiero-sdk-js/blob/main/tck/methods/node.ts (`updateNode`)

Contributor guide

Open the contributing guide

Research direction

Read the NodeUpdateTransaction spec, tck/README.md, src/hiero_sdk_python/nodes/node_update_transaction.py, and the existing updateToken or updateTopic handlers. Implement the dataclass and handler in tck/param/node.py and tck/handlers/node.py, add tests under tests/tck/, then run the TCK NodeUpdateTransaction suite. Done means dispatch works, partial updates and specified errors behave correctly, and the suite passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
blockchain, python
Domain
blockchain, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.