hiero-ledger / hiero-ledger/hiero-sdk-python
feat(tck): implement getScheduleInfo JSON-RPC method
- Dominant language
- Python
- Stars
- 63
- Forks
- 298
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 38
Description
**Problem**
The TCK server does not implement `getScheduleInfo`, so the TCK driver's `ScheduleInfoQuery` suite cannot run against the Python SDK. The SDK query already exists: `src/hiero_sdk_python/schedule/schedule_info_query.py` (`ScheduleInfoQuery`) with `src/hiero_sdk_python/schedule/schedule_info.py` (`ScheduleInfo`).
**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 `GetScheduleInfoParams` dataclass to `tck/param/schedule.py`.
- [ ] Add a response dataclass to `tck/response/` mapping the full `ScheduleInfo` field set the spec expects (schedule ID, creator/payer account IDs, scheduled transaction body, signers, admin key, expiration time, executed/deleted timestamps, memo, wait-for-expiry, …). Follow the field-mapping pattern used by the `getTokenInfo` / `getTopicInfo` handlers — including how keys and timestamps are serialized.
- [ ] Add a `getScheduleInfo` handler to `tck/handlers/schedule.py`, registered with `@rpc_method("getScheduleInfo")`.
- [ ] Add unit tests under `tests/tck/`, then run the TCK driver's ScheduleInfoQuery suite locally.
The bulk of this issue is the response mapping, not the query itself — get the serialization of each field right per the spec, don't guess formats.
**Acceptance criteria**
- [ ] `getScheduleInfo` registered and dispatchable
- [ ] All spec-required response fields present and correctly serialized for a schedule created via `createSchedule`
- [ ] Spec error cases behave as specified (missing/invalid/non-existent `scheduleId`)
- [ ] Unit tests added and the TCK `ScheduleInfoQuery` suite passes
Spec: https://github.com/hiero-ledger/hiero-sdk-tck/blob/main/docs/test-specifications/schedule-service/ScheduleInfoQuery.md
JS reference: https://github.com/hiero-ledger/hiero-sdk-js/blob/main/tck/methods/schedule.ts (`getScheduleInfo`)
Contributor guide
Assessment
This issue has not been assessed yet.