`/v1/pipeline/transactions/status` always returns 404

[nvzhu]

Bug Report: /v1/pipeline/transactions/status always returns 404

Environment

• Branch: i23
• Commit: 4bb50ebc3 (rm trash)
• Network: 2-peer localnet (also reproduced on 4-peer)
• Date: 2026-01-16

Summary

The endpoint /v1/pipeline/transactions/status returns HTTP 404 for ALL transactions - both queued and committed. This breaks SDK polling flow for transaction confirmation.

Steps to Reproduce

# 1. Deploy fresh localnet
cd /path/to/iroha
target/debug/kagami localnet --out-dir /tmp/localnet --peers 2 --seed Iroha --sample-asset \
  --base-api-port 8080 --base-p2p-port 33337 --bind-host 127.0.0.1 --public-host 127.0.0.1
cd /tmp/localnet && IROHAD_BIN=/path/to/iroha/target/debug/irohad ./start.sh
sleep 15

# 2. Submit a transaction
CLI=/path/to/iroha/target/debug/iroha
CFG=/tmp/localnet/client.toml
$CLI --config $CFG asset mint --id "rose#wonderland#ed0120CE7FA46C9DCE7EA4B125E2E36BDB63EA33073E7590AC92816AE1E861B7048B03@wonderland" --quantity 100

# 3. Get transaction hash from Torii logs
TX_HASH=$(grep "enqueuing tx=" /tmp/localnet/peer0.log | tail -1 | sed 's/.*tx=//')
echo "Hash: $TX_HASH"

# 4. Check pipeline status - returns 404
curl -v "http://127.0.0.1:8080/v1/pipeline/transactions/status?hash=$TX_HASH"

Expected Behavior

For a queued transaction:

{"kind":"Queued","content":{"hash":"...","status":{"kind":"Queued"}}}

For a committed transaction:

{"kind":"Applied","content":{"hash":"...","status":{"kind":"Applied"},"block_height":69}}

Actual Behavior

Always returns:

HTTP/1.1 404 Not Found

Test Results

Test	Condition	Result
1	Queued tx (immediately after submit)	404
2	Committed tx (Torii hash)	404
3	Committed tx (Explorer hash)	404
4	Multiple attempts over 15 seconds	All 404
5	All hashes from explorer	All 404

Additional Finding: Hash Mismatch

The same transaction shows different hashes in different places:

Same transaction (verified by matching created_at and signature):

• Torii logs: 7ce9ede526a1fb91f5434d42b776aa6aec71d43d243a9e05548fee702af2dd8d
• Explorer API: 10cd8d4611f56c7703e30906a5caf4b7cb6eb8325f87cf8e68c2102058f84edb

Root cause:

• Explorer uses tx.hash_as_entrypoint() at explorer.rs:724
• Torii/SDK uses SignedTransaction::hash()

These produce different hashes because hash_as_entrypoint() wraps the transaction in TransactionEntrypoint::External(...) before hashing.

Code Analysis

In lib.rs:10072-10096, pipeline_status_from_state():

fn pipeline_status_from_state(app: &AppState, hash: &HashOf<SignedTransaction>) -> Option<PipelineStatusEntry> {
    let height = app.state.view().transactions().get(hash)?;  // <- Returns None
    // ...
}

The function also checks the queue at line 10126-10137:

if app.queue.all_transactions(&view).any(|tx| tx.as_ref().hash() == hash) {
    // Should return Queued status
}

But neither path returns a result.

Impact

• IrohaSwift SDK submitAndWait() times out
• IrohaJS waitForTransactionStatus() fails
• Android SDK transaction confirmation broken
• Any client polling for transaction status cannot confirm transactions

Suggested Investigation

1. Why does state.view().transactions().get(hash) return None for committed transactions?
2. Why does queue.all_transactions() not find queued transactions?
3. Should explorer and pipeline status use the same hash function?

Logs

Torii accepts and enqueues the transaction:

2026-01-15T20:11:05.625983Z INFO iroha_torii::routing: transaction accepted by Torii; enqueuing tx=7ce9ede526a1fb91f5434d42b776aa6aec71d43d243a9e05548fee702af2dd8d

Later shows it's already in blockchain:

2026-01-15T20:11:14.956167Z WARN iroha_core::queue: dropping transaction during queue pop (check_tx) tx=7ce9ede526a1fb91f5434d42b776aa6aec71d43d243a9e05548fee702af2dd8d e=InBlockchain

Transaction is committed successfully (visible in explorer with different hash).

[takemiyamakoto]

Thanks for the report. I checked the current tree around this path before replying.

A few concrete points:

• crates/iroha_torii/src/lib.rs has dedicated handler coverage for /v1/pipeline/transactions/status returning Queued and Applied for both tx.hash() and tx.hash_as_entrypoint().
• crates/iroha_data_model/src/transaction/signed.rs explicitly asserts that the signed-transaction hash and the external entrypoint hash normalize to the same underlying digest.
• newer Torii API cleanup also moved this endpoint onto the shared typed PipelineTransactionStatusResponse contract, and the current Rust client falls back to the committed-transaction query path if the status endpoint returns 404.

So this does not look like an open bug on the latest tree anymore. The report was filed against i23 commit 4bb50ebc3 on January 15, 2026, which is now fairly old.

Could you please retest on current i23 or i23-features and let us know if it still reproduces there? If it does, please include:

• the exact branch + commit,
• the exact hash you queried,
• whether that hash came from Torii logs, tx.hash(), or explorer,
• the full HTTP status/body from /v1/pipeline/transactions/status, and
• the surrounding peer log lines for transaction accepted by Torii / dropping transaction during queue pop.

If you can still reproduce it on a current head with those details, we can reopen the investigation from there.