TallyResult ID Collision Across Multiple Polls

[lcs86-dev]

Bug: TallyResult ID Collision Across Multiple Polls

Current Behavior

The subgraph fails to process tally results from Poll 1 because it conflicts with existing tally result IDs from Poll 0. This happens because TallyResult uses only the index as its ID, which starts from 0 for each new poll.

Problem Details

When processing multiple polls sequentially:

1. Poll 0's tally results are stored with IDs 0, 1, 2, ...
2. When Poll 1 starts, its tally results also try to use IDs 0, 1, 2, ...
3. This causes ID collision in the subgraph since these IDs already exist

Current Schema

type TallyResult @entity(immutable: true) {
  id: ID! # index
  result: BigInt!
  tally: Tally!
}

Proposed Solution

Modify the createOrLoadTallyResult handler to create a composite ID by combining the tally address and index:

export const createOrLoadTallyResult = (index: GraphBN, result: GraphBN, tally: Bytes): TallyResult => {
  // Create composite key by combining tally address and index
  const compositeId = `${tally.toHexString()}-${index.toString()}`;
  let tallyResult = TallyResult.load(compositeId);
  if (!tallyResult) {
    tallyResult = new TallyResult(compositeId);
    tallyResult.result = result;
    tallyResult.tally = tally;
    tallyResult.save();
  }
  return tallyResult;
};

This change:

• Creates unique IDs for each tally result by combining tally address and index
• Doesn't require schema changes
• Prevents ID collisions between different polls
• Maintains the relationship between TallyResult and Tally entities

Expected Result

After this change:

• Poll 0's tally results will have IDs like: 0xTallyAddress0-0, 0xTallyAddress0-1, ...
• Poll 1's tally results will have IDs like: 0xTallyAddress1-0, 0xTallyAddress1-1, ...

This ensures each tally result has a unique identifier while maintaining the existing schema structure.

[ctrlc03]

@lcs86-dev Thank you for submitting this issue, the team will take a look at it in the new year :)