Indexing rules by subgraph id

[fordN]

This PR adds support for defining indexing rules by subgraph id (rather than deployment id). Defining rules at a subgraph level allows the indexer-agent to automatically manage versioning; keeping both the current and previous version synced and allocated towards.

Changes:

• Update indexing-rule model: deployment --> identifier & identifierType
• CLI interface unchanged but now supports providing subgraph ids where deployment ids were the only supported ids previously.
• Rules by subgraph id are processed into deployment based rules, so the reconciliation logic doesn't need to change.

[fordN]

Probably going to want to parameterize this, so indexers can set the period for which they continue to support the previous version.

[hopeyen]

Looks great 👍 Haven't tried it locally as the indexer-agent still crashes for me, so the comments are only from reading 🥸

[hopeyen]

Env all set up :D I'm crashing on the error IE017 below. Migration was successful, and a default global indexing rule was created with params identifier: "global", identifierType: "group", allocationAmount: "10000000000000000", parallelAllocations: 1, decisionBasis: "rules"

      "message": "Failed to ensure default global indexing rule",
       "code": "IE017",
      "explanation": "https://github.com/graphprotocol/indexer/blob/master/docs/errors.md#ie017",
      "cause": {
        "type": "b",
        "message": "[GraphQL] column \"identifier\" of relation \"IndexingRules\" does not exist",
        "name": "CombinedError",
        "graphQLErrors": [
          {
            "message": "column \"identifier\" of relation \"IndexingRules\" does not exist",
            "locations": [],
            "path": [
              "setIndexingRule"
            ],
            "extensions": {}
          }
        ]
      }

[hopeyen]

I think this is probably because my schema isn't updating, so I'm not sure if we would need to revisit printIndexingRules or displayIndexingRules. My indexer CLI's rules get all is missing the identifier column like this

┌──────────────────┬─────────────────────┬─────────────────────────┬───────────┬───────────┬──────────┬─────────────────────┬────────┬───────────────┐
│ allocationAmount │ parallelAllocations │ maxAllocationPercentage │ minSignal │ maxSignal │ minStake │ minAverageQueryFees │ custom │ decisionBasis │
├──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┼───────────────┤
│ 50,000.0         │ 1                   │ null                    │ null      │ null      │ null     │ null                │ null   │ never         │
├──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┼───────────────┤
│ 50,000.0         │ null                │ null                    │ null      │ null      │ null     │ null                │ null   │ never         │
├──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┼───────────────┤
│ null             │ null                │ null                    │ null      │ null      │ null     │ null                │ null   │ always        │
├──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┼───────────────┤
│ 50,000.0         │ null                │ null                    │ null      │ null      │ null     │ null                │ null   │ always        │

[hopeyen]

I'm trying to understand the handling for convertSubgraphBasedRulesToDeploymentBased. If there is an existing deployment based rule and subgraph based rule on the same deployment but with different parameters, should the subgraphBased rule trump the deployment rule?

[fordN]

@hopeyen I've created this function to check if a deployment based rule already exists in the db. I use this below in convertSubgraphBasedRulesToDeploymentBased to check for existing deployment rules before creating them. This way any user defined deployment rules take precedent over subgraph based rules. I'll make note of this order of precedent in the documentation.