feat: speed up DIPs on-chain acceptance under backlog#1200
Open
MoonBoi9001 wants to merge 1 commit into
Open
Conversation
c4d0d52 to
861cddf
Compare
MoonBoi9001
added a commit
to edgeandnode/local-network
that referenced
this pull request
Apr 25, 2026
The indexer-agent's DIPs accept gate (graphprotocol/indexer#1200) queries the indexing-payments-subgraph for OfferStored entities before calling acceptIndexingAgreement. Without a configured endpoint the gate is a no-op and a dropped offer() tx loses the agreement to a permanent deterministic rejection. Set INDEXER_AGENT_INDEXING_PAYMENTS_SUBGRAPH_ENDPOINT alongside the existing INDEXER_AGENT_OFFCHAIN_SUBGRAPHS so the agent picks up the gate as soon as the subgraph deployment is detected. Also add inline shellcheck directives to silence pre-existing SC1091 / SC2153 notes the post-edit-lint hook surfaced.
78f4c6c to
790355a
Compare
33c5e22 to
76346c1
Compare
Base automatically changed from
feat/dips-new-subgraph
to
feat/dips-on-chain-cancel
April 28, 2026 19:37
Base automatically changed from
feat/dips-on-chain-cancel
to
feat/dips-on-chain-collect
April 28, 2026 20:09
f792bc2 to
078630f
Compare
2f6c404 to
4e965d5
Compare
d6e4df1 to
e15eb66
Compare
Member
Author
|
Rebased on #1216 |
3386f36 to
01053fa
Compare
9b082b7 to
19ef3d0
Compare
19ef3d0 to
c90d378
Compare
The agent accepted DIPs agreements only on its 120s reconcile cycle, so under backlog they expired past the 300s deadline. This adds a dedicated 5s loop that accepts proposals in parallel (one per deployment, nonce-serialised) and creates the rule up front to deploy early.
c90d378 to
1c1fb04
Compare
Maikol
approved these changes
May 29, 2026
| import { sequentialTimerMap } from '../sequential-timer' | ||
| import { OfferVerifier } from './offer-verifier' | ||
|
|
||
| const DIPS_ACCEPTANCE_INTERVAL = 5_000 |
Member
There was a problem hiding this comment.
should we make this values configurable?
| // markAccepted clears the pending row, so the deployment drops out of the | ||
| // reconcile target set until the subgraph indexes the agreement. Shield | ||
| // its rule from the reaper meanwhile. | ||
| this.recentlyAcceptedDeployments.set( |
Member
There was a problem hiding this comment.
given the explanation needed for this line I would extract this to a new function and avoid the duplication in acceptWithExistingAllocation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
Under a backlog, DIPs agreements were timing out before the agent accepted them on-chain, because acceptance only ran on the agent's slow two-minute housekeeping cycle. This gives acceptance its own fast loop that works through pending agreements in parallel, so they land well inside the window they stay open for. It also keeps a just-accepted agreement's indexing rule in place until the network's record of that agreement catches up.
Motivation
The indexer-agent accepts DIPs agreements on-chain, but today it only does that on its general housekeeping cycle, which runs every two minutes. On a fresh deploy with a backlog, working through the pending agreements takes several of those cycles — longer than the five-minute window an agreement stays open for — so agreements expire before they are accepted and the indexer loses the work.
Accepting in parallel also means the agent writes down the indexing rule for an agreement the moment it is accepted, before the network's published record of that agreement is visible to the agent. The same housekeeping cycle removes rules that have no matching agreement, so without care it would delete that brand-new rule and undo the acceptance; this change keeps a just-accepted rule in place until the network's record catches up.
Summary