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

feat(tck): implement contractInfoQuery JSON-RPC method

Open
#2,604 6 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 `contractInfoQuery`, so the TCK driver's `ContractInfoQuery` suite cannot run against the Python SDK. The SDK query already exists: `src/hiero_sdk_python/contract/contract_info_query.py` (`ContractInfoQuery`) with `src/hiero_sdk_python/contract/contract_info.py` (`ContractInfo`).

**Blocked by #2594 (`createContract`)** — it creates the contract-service TCK modules, and this suite needs a deployed contract to query.

**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 a `ContractInfoQueryParams` dataclass to `tck/param/contract.py`.
- [ ] Add a response dataclass mapping the full `ContractInfo` field set the spec expects (contract/account IDs, EVM address, admin key, expiration, auto-renew settings, storage, memo, balance, deleted flag, staking info, …). Follow the field-mapping pattern of `getTokenInfo` / `getAccountInfo`, including key and timestamp serialization.
- [ ] Add a `contractInfoQuery` handler registered via `@rpc_method("contractInfoQuery")`.
- [ ] Add unit tests under `tests/tck/`, then run the TCK driver's ContractInfoQuery suite locally.

**Acceptance criteria**

- [ ] `contractInfoQuery` registered and dispatchable
- [ ] All spec-required response fields present and correctly serialized
- [ ] Spec error cases behave as specified (missing/invalid/non-existent `contractId`)
- [ ] Unit tests added and the TCK `ContractInfoQuery` suite passes

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

Contributor guide

Open the contributing guide

Research direction

First read the ContractInfoQuery spec and tck/README.md, then inspect an existing handler in tck/handlers/ with its matching tck/param/ dataclass. Review src/hiero_sdk_python/contract/contract_info_query.py and contract_info.py, and use the getTokenInfo or getAccountInfo mapping pattern. Add the parameter and response dataclasses, registered handler, and tests under tests/tck/; done means unit tests and the TCK ContractInfoQuery suite pass after #2594.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, blockchain, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.