---
# System prepended metadata

title: Legacy-curate-gnosis query irregularities

---

# Legacy-curate-gnosis query irregularities

### Overview 
  
  We migrated one of our subgraph, from using ipfs.cat to file datasource.

 old subgraph : https://thegraph.com/explorer/subgraphs/2hP3hyWreJSK8uvYwC4WMKi2qFXbPcnp7pCx7EzW24sp?view=Query&chain=arbitrum-one

new migrated subgraph : https://thegraph.com/explorer/subgraphs/9hHo5MpjpC1JqfD3BsgFnojGurXRHTrHWcUcZPPCo6m8?view=Query&chain=arbitrum-one

old code :- 
   https://github.com/kleros/gtcr-subgraph/commit/6494aa9aa93e6b04f11b534741396051c8dcbdd5

new code :-  https://github.com/kleros/gtcr-subgraph/tree/feat/fix-request-requester

### Error
 When we run this query on the [old](https://thegraph.com/explorer/subgraphs/2hP3hyWreJSK8uvYwC4WMKi2qFXbPcnp7pCx7EzW24sp?view=Query&chain=arbitrum-one) subgraph, we get 12 items
 but when we run this on [new](https://thegraph.com/explorer/subgraphs/9hHo5MpjpC1JqfD3BsgFnojGurXRHTrHWcUcZPPCo6m8?view=Query&chain=arbitrum-one) subgraph we get 7, 
 but if we deploy the new subgraph, with the same code as the new subgraph (with whitespaces to change deploy id), we get 0
 
 ```@gql
 {
  lregistry(id:"0xae6aaed5434244be3699c56e7ebc828194f26dc3"){
    numberOfAbsent
    numberOfRegistered
    items{
      id
      data
    }
  }
}
 ```
 
 - The subgraph i have at my personal account with the same code as the new one (apart from some minor changes) accounts for all the 12 items
 - subgraph on personal acc : https://testnet.thegraph.com/explorer/subgraphs/2vuXYAwSyeQDgdNaimyjL4fp7uqX4bom5Q9ThkEfZQkg?view=Query&chain=arbitrum-sepolia

---
 ### Reproduction
 1. Use this [code](https://github.com/kleros/gtcr-subgraph/tree/feat/fix-request-requester) to deploy the subgraph for gnosis
 ```@
    yarn codegen:gnosis
    yarn build:gnosis
    # deploy to your studio with "graph deploy --studio name"

 ```
 2. Make sure to add some white space to change the deployment id

---
### How the entities are created?
 
 - A new `Registry`(a contract) is created with an event `NewGTCR`, which creates a `Registry` entity and also creates a datasource. 

- When new items are added to this registry, event `NewItem` is emitted, which the datasource should handle? now this handler should create an item entity and have **item.registry = event.address.toHexString()** , which is the Registry Id. 
Along with that a new file datasource is created to parse the ipfs uri. (Present in **event.params._data**).

The items are linked to Registry entity with reference

**handler-for-Registry** : https://github.com/kleros/gtcr-subgraph/blob/a907d7eec8a10cdcaadb98b511356960710b549c/src/LightGTCRFactoryMapping.ts#L7

**handler-for-New-Item**: https://github.com/kleros/gtcr-subgraph/blob/a907d7eec8a10cdcaadb98b511356960710b549c/src/LightGeneralizedTCRMapping.ts#L220

**file-datasource-creation-in-the-new-item-handler** : https://github.com/kleros/gtcr-subgraph/blob/a907d7eec8a10cdcaadb98b511356960710b549c/src/LightGeneralizedTCRMapping.ts#L257C1-L262C62 

> the items are there for older registries, it's only the newer registries missing these items (not pretty sure but as far as i have looked the older ones have their items)

---

### Attempts to debug

#### 1. Deploy a new subgraph
   - It initially syncs instantly since the code is same, but if i add some whitespaces to change the hash and deploy again.
    It gives us 0 items now.
  - subgraph : https://testnet.thegraph.com/explorer/subgraphs/GR5iNMD8eurY4HybJjBHAn9JM3z66j54XaJd9MX4TU7d?view=Query&chain=arbitrum-sepolia  

#### 2. Redeploy without feature ipfsOnEthereumContracts
    
- Same result as above, no items at all
- Subgraph : https://testnet.thegraph.com/explorer/subgraphs/Gcpfvg5beHse9Cs6tyujXvUEupN4gNEztnsUqZSR25Xy?view=Query&chain=arbitrum-sepolia

#### 3. Deploy a graph and then use it as a graft base for a new version

- This one is pretty weird
- First deploy a subgraph, it should sync instantly (same code)
- now use the first one (v0.0.1) as a graft base and deploy a new version v0.0.2
- use the block #33599999 as the graft block, since this is the block after which the affected Registry is created.
> The registry : https://gnosisscan.io/address/0xae6aaed5434244be3699c56e7ebc828194f26dc3

- now deploy the v0.0.2 and let it sync
- once synced all the 12 items are there. Don't know how.

> Other registries might also be affected, we happen to notice this bug in the 0xae6aaed5434244be3699c56e7ebc828194f26dc3 registry first.

v0.0.1 :- https://testnet.thegraph.com/explorer/subgraphs/FYdj1eiQLmjVZsTmrDmnDK9qo2xN4HYVZsS42AfZqd1A?view=Query&chain=arbitrum-sepolia
(it has 7 items since it has same id as the legacy-curate-gnosis subgraph, the new one)

v0.0.2 :- https://testnet.thegraph.com/explorer/subgraphs/FYdj1eiQLmjVZsTmrDmnDK9qo2xN4HYVZsS42AfZqd1A?view=Query&chain=arbitrum-sepolia
(this has 12 items)



#### My take on this
 Something went wrong with the graph nodes when we had 7 items and all items after that got lost.
 
 Or maybe an issue with datasources , idk if there's any limit to how many data sources there can be
 
 I am pretty sure there is nothing wrong with the mappings since the grafted ones do return the 12 items, which would not be possible if the mappings were buggy.
 
 That's all folks
