graphprotocol / graphprotocol/dipper

Remove dead indexer RPC endpoints: cancel_agreement and collect_payment

Open
#608 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
0
Forks
1
Avg merge
37m
Merged PRs (30d)
3

Description

Motivation

Dipper's indexer-facing gRPC server (indexer_rpc) exposes two endpoints that are no longer part of the active protocol flow:

  • collect_payment — already an explicit unimplemented stub since PR #574. Payment collection is handled entirely on-chain via RecurringCollector.
  • cancel_agreement — has working server-side handling (signature verification, operator lookup, enqueues process_indexing_agreement_indexer_cancellation), but has no production callers. The only trigger is the agent-side blocklist path (DipsManager._tryCancelAgreement), and even that is marginal. The public method tryCancelAgreement(allocationId) is exported but never called from agent reconciliation loops.

Both endpoints are artefacts of the pre-on-chain architecture. With the migration to on-chain agreements and the offer-based authorization path, cancellation is handled on-chain: the indexer (or dipper) calls the contract directly, the event is emitted, the subgraph indexes it, and dipper's chain_listener detects the state change. The off-chain gRPC cancellation is redundant — it introduces a second pathway that must stay consistent with the on-chain source of truth without adding meaningful capability.

The collect_payment endpoint was part of the off-chain voucher system that was abandoned before deployment. It has been a dead stub for months.

Scope

This spans three codebases. The dead code in each:

dipper (this repo)

Server-side handlers:

  • bin/dipper-service/src/indexer_rpc_server/handlers.rs — the cancel_agreement and collect_payment implementations on the GatewayDipsService trait
  • bin/dipper-service/src/indexer_rpc_server/service.rs — the tonic server setup that registers the GatewayDipsServiceServer
  • bin/dipper-service/src/signing/eip712.rsrecover_dips_cancellation_msg_signer (used only by cancel_agreement handler). If this is the last consumer of the EIP-712 signer module, the entire module can go.
  • bin/dipper-service/src/worker/handlers/ — the process_indexing_agreement_indexer_cancellation worker handler enqueued by cancel_agreement
  • bin/dipper-service/src/main.rs — the indexer RPC server spawn and context wiring

Proto definitions:

  • dipper-rpc/src/indexer/ — the GatewayDipsService proto with CancelAgreement and CollectPayment RPCs, plus the Solidity-side SignedCancellationRequest type

Config:

  • bin/dipper-service/src/config.rsindexer_rpc config section (listen_addr, allowlist). If no other endpoint needs the indexer RPC server, remove the entire server and its config.
indexer-rs (graphprotocol/indexer-rs)

Stub handler:

  • crates/dips/src/server.rscancel_agreement is an unimplemented stub that returns Status::unimplemented. It only exists to satisfy the proto trait.

Proto definitions:

  • crates/dips/src/proto/ — the generated CancelAgreementRequest, CancelAgreementResponse, and CollectPaymentRequest/CollectPaymentResponse types. These come from the shared .proto file — if dipper drops them from the proto, indexer-rs codegen will stop producing them automatically.
indexer agent (graphprotocol/indexer)

gRPC client:

  • packages/indexer-common/src/indexing-fees/gateway-dips-service-client.tscreateGatewayDipsServiceClient which constructs the gRPC client, plus cancelAgreementDomain and cancelAgreementTypes EIP-712 constants used for signing cancellation requests
  • packages/indexer-common/src/indexing-fees/dips.tstryCancelAgreement(allocationId), _tryCancelAgreement(agreement), and the gatewayDipsServiceClient field on DipsManager. The CancelAgreement call at line 116 is the only gRPC call the agent makes to dipper.

Blocklist path:

  • packages/indexer-common/src/indexing-fees/dips.ts:851_tryCancelAgreement is called when the agent detects a NEVER indexing rule for a deployment with an active agreement. This needs to be replaced with an on-chain cancellation call (the agent already has contract interaction infrastructure for acceptIndexingAgreement).

Note: Maikol has been actively working on DIPs agent-side features. Confirm with him before removing cancel_agreement client code — he may have plans for it or may prefer to handle the agent-side cleanup himself.

What to check before removing

  1. Grep all three codebases for CancelAgreement, cancel_agreement, CollectPayment, collect_payment, GatewayDipsService to find any references beyond what's listed above.
  2. Verify that dipper's chain_listener correctly handles indexer-initiated on-chain cancellations (the IndexingAgreementCanceled event path). If it does, the off-chain notification path is fully redundant.
  3. Check whether the .proto file lives in dipper or in a shared proto repo. If shared, coordinate the proto change across all consumers.
  4. The agent's blocklist cancellation path (line 851) needs a replacement — either call the contract directly or remove the auto-cancel-on-blocklist behaviour entirely.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by grepping the three codebases for CancelAgreement, cancel_agreement, CollectPayment, collect_payment, and GatewayDipsService, beginning with the listed Rust and TypeScript files. Verify the chain_listener IndexingAgreementCanceled path and coordinate any shared proto changes before removing the endpoints. Done means obsolete handlers, clients, types, configuration, and worker paths are removed, with the agent blocklist behavior resolved.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, typescript
Domain
api, backend, blockchain
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.