Skip to content

fix(contract): support inconsistency testing EVM time #386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

airinterface
Copy link
Collaborator

Pull Request Template

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Screenshots

If applicable, add screenshots to help explain your problem.

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes timing inconsistencies in EVM contract tests by replacing strict equality assertions with more flexible range-based assertions. The change addresses the inherent timing uncertainty in blockchain testing environments where block timestamps may not be precisely controlled.

  • Replaces exact timestamp matching with acceptable range assertions (±1 second tolerance)
  • Adds comprehensive documentation explaining the EVM timing behavior
  • Updates multiple test assertions to handle timing edge cases consistently

Comment on lines +194 to +198
expect(elapsedTime).to.oneOf([
expectedElapsedTime,
expectedElapsedTime + 1n,
expectedElapsedTime - 1n,
]);
Copy link
Preview

Copilot AI Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The timing tolerance logic is duplicated across multiple test assertions. Consider extracting this into a helper function like expectTimeWithTolerance(actualTime, expectedTime, tolerance = 1n) to reduce code duplication and improve maintainability.

Suggested change
expect(elapsedTime).to.oneOf([
expectedElapsedTime,
expectedElapsedTime + 1n,
expectedElapsedTime - 1n,
]);
expectTimeWithTolerance(elapsedTime, expectedElapsedTime);

Copilot uses AI. Check for mistakes.

@@ -184,7 +184,18 @@ describe("HatsTimeFrameModule", () => {
roleHatId,
]);

expect(elapsedTime - 1n).to.equal(expectedElapsedTime);
/**
Copy link
Preview

Copilot AI Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] The comment explains the timing behavior well, but it should be moved to the top of the test function or extracted as a module-level comment since this timing issue affects all assertions in the test, not just this specific one.

Copilot uses AI. Check for mistakes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant