Conversation
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
1 participant
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.
Closing an allocation while the indexer is over-allocated leaves it open. The agent sends collect alone in that case, expecting the SubgraphService to force-close the allocation, but since the current SubgraphService implementation collect resizes it to zero instead. The transaction succeeds, no AllocationClosed is emitted, and the agent reports IE015. Operators see it after delegators undelegate: a batch where some allocations close and others stay open with zero tokens.
This drops the over-allocated branch added in #1154, so both the action queue (populateUnallocateTransaction) and the direct close resolver always multicall collect and stopService. stopService has no over-allocation guard and closes the downsized allocation normally.
Verified with a new unit test in unallocate.test.ts that fails on main. Against the contracts, a forge test from the over-allocated setup in indexing.t.sol confirms that collect alone leaves the allocation open at zero tokens and that multicall(collect, stopService) closes it. The live implementations on Arbitrum One and Arbitrum Sepolia match bytecode, so both already have the resize behaviour.