-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
jobs: flake in TestRegistryLifecycle/rollback #52767
Comments
Hi @knz, please add a C-ategory label to your issue. Check out the label system docs. While you're here, please consider adding an A- label to help keep our repository tidy. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
I'll add a commit to skip the test for the time being. |
|
|
Have you tried the git SHA where the issue was found originally. It's possible the root cause has been fixed on |
What would be that SHA? TC information is extremely hard to parse. |
You always have two differnt ways to identify this: |
52836: bulkio: Make incremental scheduled backup wait for full backup. r=miretskiy a=miretskiy Fixes #52835 Add ability to record schedule groups: set of related schedules. Use this functionality to makean incremental schedule wait until the full one completes before it begins its execution. Release Notes: None 53016: jobs: unskip TestRegistryLifecycle/rollback r=spaskob a=spaskob The test flakiness was introduced by #52697 and fixed by #52710. Fixes #52767. Release note: none. 53018: colexec: create new message to send metadata in unordered synchronizer r=yuzefovich a=asubiotto This commit fixes a race condition where a metadata message would be double-freed and therefore the same object returned to two different goroutines from a sync.Pool. The root cause of this issue was that input goroutines in the parallel unordered synchronizer use a single message that is sent repeatedly over a channel instead of multiple messages to avoid allocations. A scenario could occur where an input would drain metadata and set its message's metadata field while its message was still unread in the channel. The message would then be sent on the channel again, and the synchronizer's DrainMeta method would read the first message with the metadata field set, followed by the same message a second time. This results in returning the same metadata message twice to the distsql receiver, which would release the same metadata twice. The solution is to instead allocate a new message when draining, which will leave message already present in the channel untouched. Release note: None (no release with bug) Fixes #52890 Fixes #52948 Co-authored-by: Yevgeniy Miretskiy <[email protected]> Co-authored-by: Spas Bojanov <[email protected]> Co-authored-by: Alfonso Subiotto Marques <[email protected]>
Found in https://teamcity.cockroachdb.com/buildConfiguration/Cockroach_UnitTests/2178285?
The text was updated successfully, but these errors were encountered: