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

ccl/streamingccl/streamingest: TestTenantStreaming failed #82706

Closed
Tracked by #83319
cockroach-teamcity opened this issue Jun 10, 2022 · 3 comments · Fixed by #83358
Closed
Tracked by #83319

ccl/streamingccl/streamingest: TestTenantStreaming failed #82706

cockroach-teamcity opened this issue Jun 10, 2022 · 3 comments · Fixed by #83358
Assignees
Labels
branch-master Failures and bugs on the master branch. C-test-failure Broken test (automatically or manually discovered). O-robot Originated from a bot. skipped-test T-disaster-recovery

Comments

@cockroach-teamcity
Copy link
Member

cockroach-teamcity commented Jun 10, 2022

ccl/streamingccl/streamingest.TestTenantStreaming failed with artifacts on master @ e1cdb469d4828e2e1df0f801ac50d4e4f9943e1e:

=== RUN   TestTenantStreaming
    test_log_scope.go:79: test logs captured to: /artifacts/tmp/_tmp/045fecfe9e18c9da6f776a53d446f2c5/logTestTenantStreaming711556021
    test_log_scope.go:80: use -show-logs to present logs inline
    stream_ingestion_job_test.go:191: error executing 'SELECT * FROM d.t1': pq: no healthy sql instances available for planning
    panic.go:661: -- test log scope end --
--- FAIL: TestTenantStreaming (62.10s)

Parameters: TAGS=bazel,gss

Help

See also: How To Investigate a Go Test Failure (internal)

/cc @cockroachdb/bulk-io

This test on roachdash | Improve this report!

Jira issue: CRDB-16620

@cockroach-teamcity cockroach-teamcity added branch-master Failures and bugs on the master branch. C-test-failure Broken test (automatically or manually discovered). O-robot Originated from a bot. labels Jun 10, 2022
@stevendanna stevendanna self-assigned this Jun 13, 2022
@ajwerner
Copy link
Contributor

I looked into this a bit. The deal is that sometimes we don't find any sql instances here:

instances, err := dsp.sqlInstanceProvider.GetAllInstances(ctx)
if err != nil {
return nil, err
}
if len(instances) == 0 {
return nil, errors.New("no healthy sql instances available for planning")
}

Probably we should always find ourself. That will take a tweak down in the SQLInstance layer.

ajwerner added a commit to ajwerner/cockroach that referenced this issue Jun 13, 2022
ajwerner added a commit to ajwerner/cockroach that referenced this issue Jun 13, 2022
craig bot pushed a commit that referenced this issue Jun 13, 2022
82837: ccl/streamingccl/streamingest: skip flakey TestTenantStreaming r=ajwerner a=ajwerner

Touches #82706.

Release note: None

Co-authored-by: Andrew Werner <[email protected]>
@ajwerner
Copy link
Contributor

@rharding6373 this may be of interest to you.

rharding6373 added a commit to rharding6373/cockroach that referenced this issue Jun 27, 2022
Before this change, there was a race condition where the instance
provider and the instance reader would start before the instance
provider created a SQL instance, potentially causing the reader to not
cache the instance before initialization was complete. This is
a problem in multi-tenant environments, where we may not be able to plan
queries if the reader does not know of any SQL instances.

This change moves sql instance initialization into the instance
provider's `Start()` function before starting the reader, so that the
instance is guaranteed to be visible to the reader on its first
rangefeed scan of the `system.sql_instances` table.

Fixes: cockroachdb#82706
Fixes: cockroachdb#81807
Fixes: cockroachdb#81567

Release note: None
rharding6373 added a commit to rharding6373/cockroach that referenced this issue Jun 29, 2022
Before this change, there was a race condition where the instance
provider and the instance reader would start before the instance
provider created a SQL instance, potentially causing the reader to not
cache the instance before initialization was complete. This is
a problem in multi-tenant environments, where we may not be able to plan
queries if the reader does not know of any SQL instances.

This change moves sql instance initialization into the instance
provider's `Start()` function before starting the reader, so that the
instance is guaranteed to be visible to the reader on its first
rangefeed scan of the `system.sql_instances` table.

Fixes: cockroachdb#82706
Fixes: cockroachdb#81807
Fixes: cockroachdb#81567

Release note: None
rharding6373 added a commit to rharding6373/cockroach that referenced this issue Jun 30, 2022
Before this change, there was a race condition where the instance
provider and the instance reader would start before the instance
provider created a SQL instance, potentially causing the reader to not
cache the instance before initialization was complete. This is
a problem in multi-tenant environments, where we may not be able to plan
queries if the reader does not know of any SQL instances.

This change moves sql instance initialization into the instance
provider's `Start()` function before starting the reader, so that the
instance is guaranteed to be visible to the reader on its first
rangefeed scan of the `system.sql_instances` table.

Fixes: cockroachdb#82706
Fixes: cockroachdb#81807
Fixes: cockroachdb#81567

Release note: None
rharding6373 added a commit to rharding6373/cockroach that referenced this issue Jun 30, 2022
Before this change, there was a race condition where the instance
provider and the instance reader would start before the instance
provider created a SQL instance, potentially causing the reader to not
cache the instance before initialization was complete. This is
a problem in multi-tenant environments, where we may not be able to plan
queries if the reader does not know of any SQL instances.

This change moves sql instance initialization into the instance
provider's `Start()` function before starting the reader, so that the
instance is guaranteed to be visible to the reader on its first
rangefeed scan of the `system.sql_instances` table.

Fixes: cockroachdb#82706
Fixes: cockroachdb#81807
Fixes: cockroachdb#81567

Release note: None
rharding6373 added a commit to rharding6373/cockroach that referenced this issue Jun 30, 2022
Before this change, there was a race condition where the instance
provider and the instance reader would start before the instance
provider created a SQL instance, potentially causing the reader to not
cache the instance before initialization was complete. This is
a problem in multi-tenant environments, where we may not be able to plan
queries if the reader does not know of any SQL instances.

This change moves sql instance initialization into the instance
provider's `Start()` function before starting the reader, so that the
instance is guaranteed to be visible to the reader on its first
rangefeed scan of the `system.sql_instances` table.

Fixes: cockroachdb#82706
Fixes: cockroachdb#81807
Fixes: cockroachdb#81567

Release note: None
@craig craig bot closed this as completed in 90b15cf Jul 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch-master Failures and bugs on the master branch. C-test-failure Broken test (automatically or manually discovered). O-robot Originated from a bot. skipped-test T-disaster-recovery
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants