[memplethee-lab]

Summary

getOpenDisputes(), getDisputeHistory() and getDisputesByResolver() each read a contract method that does not exist, so all three failed on every call.

Verified against Lead-Studios/veritix-contract @ 7e090f4 and the contract rebuild backlog. The contract repo at that ref is pre-reset and does not itself compile, so entrypoints were confirmed from src/dispute.rs and the #[contractimpl] declarations in src/contract.rs.

What changed

getDisputeHistory() — fixed against a real entrypoint

Reads get_dispute_history_for_escrow(escrow_id) instead of get_dispute_history, which does not exist. The return type is unchanged: the contract returns Vec<u32>, which is exactly what this method already handed back, so there is no caller-facing shape change.

getOpenDisputes() — now rejects with NotImplemented

This one cannot be built from anything the contract exposes:

• get_dispute_stats() exists but returns only aggregate counters — open, resolved_for_beneficiary, resolved_for_depositor, expired.
• is_dispute_open(escrow_id) is a per-escrow boolean that needs an escrow id to start from, so it cannot enumerate.

There is no way to list open disputes contract-wide, so it rejects with VeriTixErrorCode.NotImplemented naming the missing entrypoint rather than issuing a call that fails with an opaque RPC error.

getDisputesByResolver() — now rejects with NotImplemented

The contract keeps no resolver-keyed dispute index. The closest real entrypoint, get_resolver_stats(resolver), returns counters (resolver, total_resolved, for_beneficiary, for_depositor) rather than the disputes themselves, so it cannot stand in for a listing either.

Both rejections name the contract function that would be needed, so the gap is actionable from the SDK side:

getOpenDisputes: the contract exposes no contract-wide open-dispute listing —
get_dispute_stats() returns only counters. Missing contract function:
get_open_disputes() -> Vec<DisputeRecord>

Implementation notes

• Signatures are unchanged, so DisputeModule needs no edit — it still forwards to these three.
• Both rejecting functions return Promise.reject(...) rather than being async functions that throw. DisputeModule returns these directly instead of awaiting them, so an async throw would surface synchronously through that wrapper; Promise.reject keeps it asynchronous on every path.
• The unused invoker parameter is _-prefixed to satisfy @typescript-eslint/no-unused-vars (argsIgnorePattern: "^_").
• The decodeDisputeRecord import and its docblock are removed — with both decoders gone this file no longer decodes dispute structs.

Breaking changes

None. No signature or return type changed. getOpenDisputes() and getDisputesByResolver() now reject with a typed VeriTixError (NOT_IMPLEMENTED) where they previously rejected with an RPC-level failure, which is catchable and inspectable rather than a change in what the calls do.

Contract-side follow-up

The issue asks for a contract-side issue to be opened for the entrypoints that are wanted. The two gaps, in the shape they'd need:

• get_open_disputes() -> Vec<DisputeRecord> — a contract-wide enumeration of disputes with status == open.
• get_disputes_by_resolver(resolver: Address) -> Vec<DisputeRecord> — a resolver-keyed index, mirroring the existing get_disputes_by_claimant(claimant) -> Vec<u32> but returning records rather than ids.

Once either lands, the corresponding method here is a one-line change from Promise.reject(...) to a simulateRead + decode.

Not opened here because this PR is scoped to the SDK repo — flagging for the maintainer.

Tests

tests/dispute.test.ts covers all three of these and will need updating: the getDisputeHistory blocks assert the old get_dispute_history method name, and the getOpenDisputes / getDisputesByResolver blocks assert successful decodes that can no longer happen. No tests were run or changed in this PR.

Closes #853

[drips-wave]

@memplethee-lab Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits