Add lock around dummy DA data

[Manav-Aggarwal]

Overview

Closes: #22

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

Summary by CodeRabbit

• Refactor

  • Improved thread-safety in data access methods by introducing mutex locks.

• Tests

  • Added a new test to ensure no race conditions occur during concurrent read/write operations.

[coderabbitai]

Warning

Rate Limit Exceeded

@Manav-Aggarwal has exceeded the limit for the number of files or commits that can be reviewed per hour. Please wait 1 minutes and 10 seconds before requesting another review.

How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.
Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.
Please see our FAQ for further information.

Commits

Files that changed from the base of the PR and between 59b40ef and b2c5865.

Walkthrough

The recent updates involve enhancing thread safety in the DummyDA struct by introducing a mutex to guard against concurrent access to its fields. Methods that interact with the protected data now lock and unlock this mutex to prevent race conditions. Additionally, a new test function ensures these thread-safety measures are effective.

Changes

File(s)	Change Summary
test/dummy.go	Added sync.Mutex to DummyDA and implemented locking in Get, GetIDs, Commit, Submit.
test/test_suite.go	Added ConcurrentReadWriteTest and imported "sync" package to test thread safety.

🐇 In the code's woven threads, we dance,
Locks and tests in a concurrent prance.
As leaves fall in a twirl,
Our mutex guards the swirl. 🍂🔒

---

Tips

Chat with CodeRabbit Bot (@coderabbitai)

• If you reply to a review comment from CodeRabbit, the bot will automatically respond.
• To engage with CodeRabbit bot directly around the specific lines of code in the PR, mention @coderabbitai in your review comment
• Note: Review comments are made on code diffs or files, not on the PR overview.
• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Note: For conversation with the bot, please use the review comments on code diffs or files.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

[coderabbitai]

Review Status

Actionable comments generated: 2

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 57bc360 and 7f99f0d.

Files selected for processing (1)

• test/dummy.go (6 hunks)

Additional comments: 4

test/dummy.go (4)

• 7-13: The import of sync is correctly added to use sync.Mutex for thread-safety. Ensure that no other parts of the codebase are affected by this addition if sync was not previously imported.

• 43-49: The use of mu.Lock() and defer mu.Unlock() is correct for ensuring that the Get method is thread-safe. The defer statement is used appropriately to ensure that the mutex is unlocked even if an error occurs and the function returns early.

• 67-73: The GetIDs method is also correctly protected with mutex locks to ensure thread-safety.

• 88-94: The Submit method is correctly using mutex locks to protect the critical section where the state is modified. The increment of d.height is also correctly placed within the locked section to prevent race conditions.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (main@57bc360). Click here to learn what that means.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #21   +/-   ##
=======================================
  Coverage        ?   84.04%           
=======================================
  Files           ?        3           
  Lines           ?      163           
  Branches        ?        0           
=======================================
  Hits            ?      137           
  Misses          ?       18           
  Partials        ?        8           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[coderabbitai]

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 7f99f0d and 59b40ef.

Files selected for processing (2)

• test/dummy.go (6 hunks)
• test/test_suite.go (3 hunks)

Files skipped from review due to trivial changes (1)

• test/dummy.go

Additional comments: 3

test/test_suite.go (3)

• 3-8: The import of the "sync" package is correctly added to support the use of sync.Mutex and sync.WaitGroup in the tests.

• 22-27: The addition of the ConcurrentReadWriteTest to the test suite is a good practice to ensure that the thread-safety mechanisms are working as intended. It's important to ensure that this test is comprehensive enough to catch potential race conditions.

• 145-146: The assertion at the end of GetIDsTest is crucial to ensure that the test data is found within the expected time frame. It's good practice to have such an assertion to confirm that the test conditions are met.