You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's common in our tests to bootstrap a dataset, let library code create as many tables as needed, then cleanup the dataset after the test finishes. Removing a dataset should remove all tables and other resources inside it.
The emulator doesn't appear to do this. Additionally, the errors returned from the emulator are 500 which the Google SDKs (at least for Go) retry indefinitely on. This is likely the cause of the deadlock: source / source
What did you expect to happen?
Two things:
When errors happen, return them as non-internalError. The Google SDKs retry on these indefinitely because they're treated as infrastructural errors on their side.
When a dataset is deleted, clean up its tables. It's much easier from a test to delete a single dataset, than to record all tables a library may have created during a test.
How can we reproduce it (as minimally and precisely as possible)?
cd$(mktemp -d)
go mod init test# Copy below test file to main_test.go
go mod tidy
go test.
package main
import (
"context""sync""testing""cloud.google.com/go/bigquery""github.com/stretchr/testify/require""github.com/testcontainers/testcontainers-go""github.com/testcontainers/testcontainers-go/wait""google.golang.org/api/option"
)
const (
bqPort="9050/tcp"testProject="project"
)
// startBigQuery spins up a test container and blocks until it's ready. Only one// container can be started per test binary.//// Sharing a container across tests improves suite duration significantlyvarstartBigQuery=sync.OnceValues(func() (testcontainers.Container, error) {
ctx:=context.Background()
returntestcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
ContainerRequest: testcontainers.ContainerRequest{
Image: "ghcr.io/goccy/bigquery-emulator:latest",
Cmd: []string{
"--project="+testProject,
},
ExposedPorts: []string{bqPort},
WaitingFor: wait.ForExposedPort(),
},
Started: true,
})
})
funcTestBasic(t*testing.T) {
t.Run("one", func(t*testing.T) {
testHelper(t)
})
t.Run("two", func(t*testing.T) {
testHelper(t)
})
}
functestHelper(t*testing.T) {
ctx:=context.Background()
// Startup emulator and create clientcontainer, err:=startBigQuery()
require.NoError(t, err)
addr, err:=container.Endpoint(ctx, "")
require.NoError(t, err)
endpoint:="http://"+addrclient, err:=bigquery.NewClient(
ctx,
testProject,
option.WithoutAuthentication(),
option.WithEndpoint(endpoint),
)
require.NoError(t, err)
// Create dataset and table withinds:=client.Dataset("main")
err=ds.Create(ctx, nil)
require.NoError(t, err)
// Cleanup entire dataset on test finisht.Cleanup(func() {
require.NoError(t, ds.Delete(ctx))
})
t.Log("creating table inside dataset")
table:=ds.Table("data")
err=table.Create(ctx, &bigquery.TableMetadata{
Schema: bigquery.Schema{
&bigquery.FieldSchema{Name: "value", Type: bigquery.NumericFieldType},
},
})
require.NoError(t, err)
// This prevents the test from deadlocking indefinitely, but removing the entire// dataset should be enough.//// Either that, or returning an appropriate error.//// t.Cleanup(func() {// require.NoError(t, table.Delete(ctx))// })t.Log("table created")
}
funcignoreErr[Tany](vT, errerror) T {
iferr!=nil {
panic(err)
}
returnv
}
Anything else we need to know?
No response
The text was updated successfully, but these errors were encountered:
What happened?
It's common in our tests to bootstrap a dataset, let library code create as many tables as needed, then cleanup the dataset after the test finishes. Removing a dataset should remove all tables and other resources inside it.
The emulator doesn't appear to do this. Additionally, the errors returned from the emulator are
500
which the Google SDKs (at least for Go) retry indefinitely on. This is likely the cause of the deadlock: source / sourceWhat did you expect to happen?
Two things:
internalError
. The Google SDKs retry on these indefinitely because they're treated as infrastructural errors on their side.How can we reproduce it (as minimally and precisely as possible)?
Anything else we need to know?
No response
The text was updated successfully, but these errors were encountered: