Implement deleteFile JSON-RPC method

[aceppaluni]

Problem

The TCK server does not implement deleteFile, so the TCK driver's FileDeleteTransaction suite cannot run against the Python SDK. The SDK transaction (src/hiero_sdk_python/file/file_delete_transaction.py) already exists.

Blocked by hiero-ledger#2488 (createFile) — this handler goes in the file-service TCK modules hiero-ledger#2488 creates, and the driver needs a created file to delete. Implementing this also unblocks a currently-skipped test in the appendFile spec ("Appends to a deleted file — Skipped (delete file not implemented)").

Solution

Add a deleteFile handler wrapping FileDeleteTransaction, modelled on the existing deleteTopic handler in tck/handlers/topic.py — same shape, substituting FileDeleteTransaction and set_file_id(FileId.from_string(...)).

Method contract (from the spec):

Input	Type	Required	Notes
fileID	string	optional	Capital ID — see trap below
commonTransactionParams	object	optional

Output: status — reuse StatusOnlyResponse from tck/response/base.py.

Implementation steps:

1. Add DeleteFileParams(BaseTransactionParams) to tck/param/file.py.
2. Add the handler to tck/handlers/file.py (mirror deleteTopic).
3. Add a unit test under tests/tck/.

Two traps — both are spec-conformance issues that will fail driver tests if missed:

1. The spec's parameter is fileID, not fileId. Every other file-service method uses fileId; this one alone uses fileID. Bind the JSON key verbatim (params.get("fileID")) or the driver's parameter won't map. Leave a comment so a future reader doesn't "fix" the inconsistency.

2. Empty string vs. omitted must behave differently. The spec's property tests expect:

   • fileId="" → SDK internal error
   • fileId omitted entirely → network INVALID_FILE_ID

   The SDK raises ValueError("Missing required FileID") for an unset file ID (file_delete_transaction.py, _require check before building), which would collapse both cases into a local error. The handler must therefore: pass "" through in a way that triggers SDK-side validation (e.g. attempt FileId.from_string(""), which raises), but when the param is absent, do not short-circuit — submit without a file ID so the network returns INVALID_FILE_ID. If the SDK's local ValueError makes the omitted case impossible to send, note that in the PR and raise it — that's a genuine SDK/spec conformance question, not something to paper over in the handler.

Other spec expectations to test: delete without the file's admin key in signers → INVALID_SIGNATURE; delete an already-deleted file → FILE_DELETED.

Acceptance criteria

• deleteFile registered and dispatchable, bound to the fileID (capital ID) parameter
• fileID="" → SDK internal error; fileID omitted → network INVALID_FILE_ID (or SDK limitation documented in PR)
• Unsigned delete → INVALID_SIGNATURE; double delete → FILE_DELETED
• Unit test added; uv run pytest tests/tck -q passes

Spec: https://github.com/hiero-ledger/hiero-sdk-tck/blob/main/docs/test-specifications/file-service/FileDeleteTransaction.md

JS reference: https://github.com/hiero-ledger/hiero-sdk-js/blob/main/tck/methods/file.ts (deleteFile)

[aceppaluni]

@learnmore Can you explain what this issue is asking me to do?

[codecoach-learning]

What This Issue Is Asking You To Do

This issue asks you to add a deleteFile method to the Python SDK's TCK (Test Compatibility Kit) server. The TCK server is a JSON-RPC server that lets an external test driver verify the SDK's behavior.

The Core Task

The SDK already has FileDeleteTransaction in src/hiero_sdk_python/file/file_delete_transaction.py. You just need to expose it through the TCK server so the test driver can call it. This involves 3 files:

---

1. tck/param/file.py — Add Input Parameters

Create a DeleteFileParams class that accepts:

• fileID (string, optional) — Note the capital ID, not fileId. This matches the spec exactly.
• commonTransactionParams (object, optional)

---

2. tck/handlers/file.py — Add the Handler

Add a deleteFile function that:

• Reads the fileID parameter from the JSON-RPC request
• Creates a FileDeleteTransaction, sets the file ID, and executes it
• Returns a StatusOnlyResponse (from tck/response/base.py)

You can model this almost exactly on the existing deleteTopic handler in tck/handlers/topic.py — it's the same pattern.

---

3. tests/tck/ — Add a Unit Test

Add a unit test verifying the handler works correctly.

---

Two Important Traps ⚠️

1. fileID not fileId — The spec uses capital ID for this one method. Don't "fix" it — the test driver sends fileID and your handler must read fileID.

2. Empty string vs. omitted parameter behave differently:

   • fileID="" → should produce an SDK internal error (e.g., FileId.from_string("") raises)
   • fileID omitted entirely → should produce a network INVALID_FILE_ID error (meaning: submit the transaction without a file ID and let the network reject it)

   These two cases must not collapse into the same error.

---

Why It Matters

Without this, the TCK driver's FileDeleteTransaction test suite can't run against the Python SDK, and a test in the appendFile spec is currently skipped waiting for this.

[jwagantall]

@learnmore What is the first step for approaching this task?

[codecoach-learning]

First Step: Understand the Existing Pattern

Before writing any new code, look at the existing deleteTopic handler in tck/handlers/topic.py. This issue explicitly says to model deleteFile on it — so understanding that implementation first will show you the exact shape your code needs to follow.

Specifically, examine:

• How deleteTopic reads its parameter from the request
• How it constructs and executes the transaction
• How it returns a StatusOnlyResponse

Then look at tck/param/topic.py to see how the corresponding params class is structured.

Once you understand that pattern, your first coding step is:

Add DeleteFileParams to tck/param/file.py

This class should extend BaseTransactionParams (look at other params classes for the import) and declare:

• fileID — a string field, optional — capital ID, not fileId
• commonTransactionParams — inherited from the base class

This is the simplest, most self-contained change and sets up the type structure the handler will depend on. Getting the field name fileID right here is critical — if you name it fileId, the driver's requests won't map correctly.

After that, you move to the handler in tck/handlers/file.py, then the unit test.

[jwagantall]

@learnmore explain the deleteTopic handler

[codecoach-learning]

The deleteTopic Handler Explained

The deleteTopic handler in tck/handlers/topic.py is the direct blueprint for what you need to build. Here's how it works conceptually:

Structure

def delete_topic(params):
    # 1. Extract the topic ID from the incoming JSON-RPC params
    topic_id = params.get("topicId")

    # 2. Build the transaction
    tx = TopicDeleteTransaction()
    
    # 3. Set the ID (if provided)
    if topic_id is not None:
        tx.set_topic_id(TopicId.from_string(topic_id))

    # 4. Apply common transaction params (fees, signers, etc.)
    handle_common_transaction_params(tx, params)

    # 5. Execute and return a status-only response
    receipt = tx.execute(client).get_receipt(client)
    return StatusOnlyResponse(status=receipt.status.name)

Key Components

Part	What it does
params.get("topicId")	Reads the ID from the JSON-RPC request body
TopicId.from_string(...)	Converts the string to the SDK's ID type; raises if invalid
handle_common_transaction_params	Applies signers, transaction ID, max fees, etc. from commonTransactionParams
StatusOnlyResponse	Returns just the network status string (e.g. "SUCCESS") — from tck/response/base.py

How deleteFile Maps to This

Your deleteFile handler follows the exact same shape, with two substitutions:

1. TopicDeleteTransaction → FileDeleteTransaction
2. set_topic_id(TopicId.from_string(...)) → set_file_id(FileId.from_string(...))

And one critical difference — the parameter name:

• deleteTopic reads "topicId"
• deleteFile must read "fileID" (capital ID) — this is the spec's naming, not a typo

The Empty vs. Omitted Distinction

Notice that params.get("topicId") returns None when absent and "" when explicitly passed as empty. Your handler needs to treat these differently:

• fileID="" → call FileId.from_string("") which raises an SDK error
• fileID absent (None) → skip set_file_id(...) entirely, submit without it, let the network return INVALID_FILE_ID

[aceppaluni]

@learnmore What is an RPC method?

[codecoach-learning]

What is an RPC Method?

RPC stands for Remote Procedure Call. It's a way for one program to call a function in another program — even if they're running as separate processes or on different machines — as if it were a local function call.

JSON-RPC specifically is a protocol where:

1. A caller sends a JSON message like: {"method": "deleteFile", "params": {"fileID": "0.0.123"}}
2. A server receives it, runs the corresponding function, and sends back a JSON response like: {"result": {"status": "SUCCESS"}}

In This Issue's Context

The TCK (Test Compatibility Kit) server is a JSON-RPC server. An external test driver (a separate test suite) sends JSON-RPC requests to it to test whether the Python SDK behaves correctly.

So deleteFile is a JSON-RPC method — it's a named function the test driver can call over the network by name. When the driver sends {"method": "deleteFile", "params": {"fileID": "0.0.123"}}, the TCK server needs a registered handler function that:

1. Receives those params
2. Calls the actual SDK's FileDeleteTransaction
3. Returns the result

Without this handler registered, the test driver's FileDeleteTransaction test suite can't run, because the server doesn't know what to do when it receives a "deleteFile" call.

In short: an RPC method is just a function you can call remotely by name, and this issue is asking you to implement the server-side handler for one such function.