Skip to content
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

timely-util: reclock: test binding consolidation #31285

Merged

Conversation

petrosagg
Copy link
Contributor

Unit test the logic added in #31248. The tests tests two extreme scenarios. In the first scenario a single big batch of unconsolidated bindings are presented to the operator. In the second scenario tiny batches of the same number of uncompacted bindings are presented to the operator over multiple steps.

Motivation

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

@petrosagg petrosagg requested a review from teskje February 4, 2025 12:01
@petrosagg petrosagg requested a review from a team as a code owner February 4, 2025 12:01
Copy link
Contributor

@teskje teskje left a comment

Choose a reason for hiding this comment

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

I don't have much context on the code here, but the tests look reasonable and if they pass, even better :)


impl Time {
fn new(time: u64) -> Self {
INSTANCES.store(INSTANCES.load(Ordering::Relaxed) + 1, Ordering::Relaxed);
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like the harness only runs a single worker, so this doesn't matter currently, but I think you want INSTANCES.fetch_add(1, Ordering::Relaxed) instead. At the very least it's more readable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, you're right, I forgot about that. I had initially implemented it with Cells, until Rust complained about Send and I blindly switched the set/get to store/load. I'll make this a fetch_add

@petrosagg petrosagg force-pushed the test-reclock-consolidation branch from 2dc58cc to d5f5433 Compare February 4, 2025 19:36
@petrosagg petrosagg enabled auto-merge February 4, 2025 19:37
@petrosagg petrosagg merged commit a9d5a81 into MaterializeInc:main Feb 4, 2025
78 checks passed
@petrosagg petrosagg deleted the test-reclock-consolidation branch February 4, 2025 20:30
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.

2 participants