You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is to revisit the definition of the recipient entity in subgraph.
Currently, the "removeRecipient" mapping rule marked recipient as 'rejected' in the subgraph when the recipient was deleted from the contract. (note: this logic only applies to simple and Kleros registry, optimistic registry has different logic).
See RecipientMapping.ts, removeRecipient() function for the mark 'rejected' code.
Also, in the function getRegistryInfo() in file /api/recipient-registry.ts, the logic gets the recipientCount from the registry contract instead of from the subgraph because it cannot simply count the recipient records. The recipient entity in the subgraph does not store recipient entity. Instead it stores the operation( requests ) on recipients generated from the optimistic recipient registry.
Will leave this issue to be tackled at a later time because the UI code that depends on the information is currently retrieving information that it needs from the contract directly as opposed to from the subgraph. This is to keep the scope of the original PR small.
The text was updated successfully, but these errors were encountered:
This issue was introduced by PR #473
The issue is to revisit the definition of the recipient entity in subgraph.
Currently, the "removeRecipient" mapping rule marked recipient as 'rejected' in the subgraph when the recipient was deleted from the contract. (note: this logic only applies to simple and Kleros registry, optimistic registry has different logic).
See RecipientMapping.ts, removeRecipient() function for the mark 'rejected' code.
Also, in the function getRegistryInfo() in file /api/recipient-registry.ts, the logic gets the recipientCount from the registry contract instead of from the subgraph because it cannot simply count the recipient records. The recipient entity in the subgraph does not store recipient entity. Instead it stores the operation( requests ) on recipients generated from the optimistic recipient registry.
Will leave this issue to be tackled at a later time because the UI code that depends on the information is currently retrieving information that it needs from the contract directly as opposed to from the subgraph. This is to keep the scope of the original PR small.
The text was updated successfully, but these errors were encountered: