ernie-research/MEnvBench huggingface dataset:
Repository: luau-lang/luau (C++)

Issue:
New on demand type checkers do not use correct globalScope
After many hours of debugging, it turns out that the new changes to on demand type checkers does not use the correct global scope when running for autocomplete.

This caused odd differences in TypeId ptrs where the TypeChecker sometimes uses a non-autocomplete type id in an autocomplete context, causing https://github.com/JohnnyMorganz/luau-lsp/issues/358

This can be seen when the FFlag `LuauOnDemandTypecheckers` is enabled

It seems to all come down to this one line: https://github.com/Roblox/luau/blob/0014905b69ff58e6b3c2c8423fe382f8866531e8/Analysis/src/Frontend.cpp#L1400

I believe it should probably be
```diff
-        TypeChecker typeChecker(globals.globalScope, forAutocomplete ? &moduleResolverForAutocomplete : &moduleResolver, builtinTypes, &iceHandler);
+        TypeChecker typeChecker(forAutocomplete ? globalsForAutocomplete.globalScope : globals.globalScope, forAutocomplete ? &moduleResolverForAutocomplete : &moduleResolver, builtinTypes, &iceHandler); 
```



Fix (patch):
diff --git a/Analysis/src/Frontend.cpp b/Analysis/src/Frontend.cpp
index b6b315cf1..b16eda8a9 100644
--- a/Analysis/src/Frontend.cpp
+++ b/Analysis/src/Frontend.cpp
@@ -38,6 +38,7 @@ LUAU_FASTFLAGVARIABLE(DebugLuauLogSolverToJson, false)
 LUAU_FASTFLAG(LuauRequirePathTrueModuleName)
 LUAU_FASTFLAGVARIABLE(DebugLuauReadWriteProperties, false)
 LUAU_FASTFLAGVARIABLE(LuauSplitFrontendProcessing, false)
+LUAU_FASTFLAGVARIABLE(LuauTypeCheckerUseCorrectScope, false)
 
 namespace Luau
 {
@@ -1397,7 +1398,9 @@ ModulePtr Frontend::check(const SourceModule& sourceModule, Mode mode, std::vect
     }
     else
     {
-        TypeChecker typeChecker(globals.globalScope, forAutocomplete ? &moduleResolverForAutocomplete : &moduleResolver, builtinTypes, &iceHandler);
+        TypeChecker typeChecker(FFlag::LuauTypeCheckerUseCorrectScope ? (forAutocomplete ? globalsForAutocomplete.globalScope : globals.globalScope)
+                                                                      : globals.globalScope,
+            forAutocomplete ? &moduleResolverForAutocomplete : &moduleResolver, builtinTypes, &iceHandler);
 
         if (prepareModuleScope)
         {
Repository: a-h/templ (Go)

Issue:
Watchmode txt files are not cleaned up
**Describe the bug**
When running `templ generate --watch` and subsequently sending an interupt signal, the txt files which usually are removed still persist.

**To Reproduce**
In any templ project:
- Run `templ generate --watch`
- Observe txt files are created
- Ctrl+C on the generate command
- Observe txt files still exist

**Expected behavior**
txt files should be deleted.

**`templ info` output**
```
(✓) os [ goos=darwin goarch=arm64 ]
(✓) go [ location=/Users/josephdavidson/.asdf/shims/go version=go version go1.23.4 darwin/arm64 ]
(✓) gopls [ location=/Users/josephdavidson/.asdf/shims/gopls version=golang.org/x/tools/gopls v0.17.1 ]
(✓) templ [ location=/Users/josephdavidson/go/bin/templ version=v0.3.819 ]
```

**Additional context**
This was an issue introduced in this commit: https://github.com/a-h/templ/commit/1f94c7b135dbb54f8a420f8201ca17b5bc6a1b93#diff-d871fda4ab49b4f5e6475e42ebccf5ca92261a30588f3d5165132dbe769587e1L188



Discussion: Yeah, that was silly of me...



Fix (patch):
diff --git a/cmd/templ/generatecmd/cmd.go b/cmd/templ/generatecmd/cmd.go
index 3b8f97ae6..246e51cd1 100644
--- a/cmd/templ/generatecmd/cmd.go
+++ b/cmd/templ/generatecmd/cmd.go
@@ -12,6 +12,7 @@ import (
 	"path/filepath"
 	"regexp"
 	"runtime"
+	"strings"
 	"sync"
 	"sync/atomic"
 	"time"
@@ -185,9 +186,26 @@ func (cmd Generate) Run(ctx context.Context) (err error) {
 		)
 		postGenerationEventsWG.Wait()
 		cmd.Log.Debug(
-			"All post-generation events processed",
+			"All post-generation events processed, deleting watch mode text files",
 			slog.Int64("errorCount", errorCount.Load()),
 		)
+
+		fileEvents := make(chan fsnotify.Event)
+		go func() {
+			if err := watcher.WalkFiles(ctx, cmd.Args.Path, cmd.WatchPattern, fileEvents); err != nil {
+				cmd.Log.Error("Post dev mode WalkFiles failed", slog.Any("error", err))
+				errs <- FatalError{Err: fmt.Errorf("failed to walk files: %w", err)}
+				return
+			}
+			close(fileEvents)
+		}()
+		for event := range fileEvents {
+			if strings.HasSuffix(event.Name, "_templ.txt") {
+				if err = os.Remove(event.Name); err != nil {
+					cmd.Log.Warn("Failed to remove watch mode text file", slog.Any("error", err))
+				}
+			}
+		}
 	}()
 
 	// Start process to handle events.
Repository: a-h/templ (Go)

Issue:
parser: Calling methods on a new line
When I try to write a method call on a new line I get an error ```expected selector or type assertion, found '.' ```

```go
templ SomeView() {
    @SomeStruct{}. // <- here
        SomeMethod() { }
}
```

Go 1.22.4 linux/amd64
Templ v0.2.707



Fix (patch):
diff --git a/parser/v2/goexpression/scanner.go b/parser/v2/goexpression/scanner.go
index 73696a668..fb9b8a94c 100644
--- a/parser/v2/goexpression/scanner.go
+++ b/parser/v2/goexpression/scanner.go
@@ -140,7 +140,7 @@ func (ep *ExpressionParser) Insert(
 	// or "call().name", "call().name()".
 	// But not "package .name" or "typeName{field: value} .name()".
 	if tok == token.IDENT && (ep.Previous == token.PERIOD || isCloser(ep.Previous)) {
-		if ep.hasSpaceBeforeCurrentToken(pos) {
+		if isCloser(ep.Previous) && ep.hasSpaceBeforeCurrentToken(pos) {
 			// This token starts later than the last ending, which means
 			// there's a space.
 			return true, nil
Repository: superfly/flyctl (Go)

Issue:
Default volume size discrepancy
The default volume size is 3 GB when you run `fly vol create`.
The default volume size 1 GB when you run `fly launch` (don't deploy) then add `[mounts]` to `fly.toml` and then run `fly deploy`. Or when you run `fly launch` with an existing fly.toml with `[mounts]`.

1 GB is also the default when scaling up from zero if there are no available volumes to get a size from.

@davissp14 suggested that `fly vol create` shouldn't have a default (and so should require the `--size` option).  



Fix (patch):
diff --git a/internal/command/deploy/deploy_first.go b/internal/command/deploy/deploy_first.go
index 705d4f18d6..bc97819dba 100644
--- a/internal/command/deploy/deploy_first.go
+++ b/internal/command/deploy/deploy_first.go
@@ -125,12 +125,8 @@ func (md *machineDeployment) provisionVolumesOnFirstDeploy(ctx context.Context)
 				initialSize, _ = helpers.ParseSize(m.InitialSize, units.FromHumanSize, units.GB)
 			case md.volumeInitialSize > 0:
 				initialSize = md.volumeInitialSize
-			case guest == nil:
-				initialSize = DefaultVolumeInitialSizeGB
-			case guest.GPUKind != "":
+			case guest != nil && guest.GPUKind != "":
 				initialSize = DefaultGPUVolumeInitialSizeGB
-			case guest.CPUKind != "shared" || guest.CPUs != 1:
-				initialSize = DefaultNonFreeVolumeInitialSizeGB
 			default:
 				initialSize = DefaultVolumeInitialSizeGB
 			}
diff --git a/internal/command/deploy/machines.go b/internal/command/deploy/machines.go
index 570f407d73..fb766127b5 100644
--- a/internal/command/deploy/machines.go
+++ b/internal/command/deploy/machines.go
@@ -24,13 +24,12 @@ import (
 )
 
 const (
-	DefaultWaitTimeout                = 5 * time.Minute
-	DefaultReleaseCommandTimeout      = 5 * time.Minute
-	DefaultLeaseTtl                   = 13 * time.Second
-	DefaultMaxUnavailable             = 0.33
-	DefaultVolumeInitialSizeGB        = 1
-	DefaultGPUVolumeInitialSizeGB     = 100
-	DefaultNonFreeVolumeInitialSizeGB = 10
+	DefaultWaitTimeout            = 5 * time.Minute
+	DefaultReleaseCommandTimeout  = 5 * time.Minute
+	DefaultLeaseTtl               = 13 * time.Second
+	DefaultMaxUnavailable         = 0.33
+	DefaultVolumeInitialSizeGB    = 3
+	DefaultGPUVolumeInitialSizeGB = 100
 )
 
 type MachineDeployment interface {
Repository: superfly/flyctl (Go)

Issue:
flyctl does not support [mount] configuration
Apps v1 allows developers to use `[mount]` or `[mounts]` (singular or plural) to specify the volumes to mount to instances.

Apps v2 only supports the `[mounts]` version.

Update flyctl to support both version for apps v2.




Fix (patch):
diff --git a/internal/appv2/patches.go b/internal/appv2/patches.go
index 3225457915..134842caf8 100644
--- a/internal/appv2/patches.go
+++ b/internal/appv2/patches.go
@@ -15,6 +15,7 @@ var configPatches = []patchFuncType{
 	patchServices,
 	patchProcesses,
 	patchExperimental,
+	patchMounts,
 }
 
 func applyPatches(cfgMap map[string]any) (*Config, error) {
@@ -243,6 +244,15 @@ func ensureArrayOfMap(raw any) ([]map[string]any, error) {
 	return out, nil
 }
 
+func patchMounts(cfg map[string]any) (map[string]any, error) {
+	if mount, ok := cfg["mount"]; ok {
+		cfg["mounts"] = mount
+	}
+	delete(cfg, "mount")
+	return cfg, nil
+
+}
+
 func stringOrSliceToSlice(input any, fieldName string) ([]string, error) {
 	if input == nil {
 		return nil, nil
Repository: cortexproject/cortex (Go)

Issue:
Error message for max series per label set is incomplete
**Describe the bug**
The [error message](https://github.com/cortexproject/cortex/blob/2ef5de076dec4c8e496eb40fbe590de01ca484b3/pkg/ingester/limiter.go#L211) returned when max series per label set limit is hit is incomplete. 

The format for the error message is `"per-labelset series limit of %d exceeded (labelSet: %s, local limit: %d global limit: %d actual)"`, note that we actually don't have a `%d` placeholder for `actual` at the end of the message. 



Discussion: @alvinlin123 welcome back! do you want to work on it?
> [@alvinlin123](https://github.com/alvinlin123) welcome back! do you want to work on it?

hahaha thanks for the welcome .... I do intend to find time to work on this ... but first come first serve :) 
@friedrichg because you assigned this issue to me, I felt obligated to find time to fix it hahaha .... please review my PR :D



Fix (patch):
diff --git a/pkg/ingester/limiter.go b/pkg/ingester/limiter.go
index bfeec07e140..69920f76229 100644
--- a/pkg/ingester/limiter.go
+++ b/pkg/ingester/limiter.go
@@ -21,9 +21,9 @@ var (
 
 type errMaxSeriesPerLabelSetLimitExceeded struct {
 	error
-	id          string
-	localLimit  int
-	globalLimit int
+	id               string
+	actualLocalLimit int
+	globalLimit      int
 }
 
 // RingCount is the interface exposed by a ring implementation which allows
@@ -130,9 +130,9 @@ func (l *Limiter) AssertMaxSeriesPerLabelSet(userID string, metric labels.Labels
 			return err
 		} else if u >= local {
 			return errMaxSeriesPerLabelSetLimitExceeded{
-				id:          limit.Id,
-				localLimit:  local,
-				globalLimit: limit.Limits.MaxSeries,
+				id:               limit.Id,
+				actualLocalLimit: local,
+				globalLimit:      limit.Limits.MaxSeries,
 			}
 		}
 	}
@@ -208,8 +208,8 @@ func (l *Limiter) formatMaxMetadataPerMetricError(userID string, metric string)
 }
 
 func (l *Limiter) formatMaxSeriesPerLabelSetError(err errMaxSeriesPerLabelSetLimitExceeded) error {
-	return fmt.Errorf("per-labelset series limit of %d exceeded (labelSet: %s, local limit: %d global limit: %d actual)",
-		minNonZero(err.globalLimit, err.localLimit), err.id, err.localLimit, err.globalLimit)
+	return fmt.Errorf("per-labelset series limit of %d exceeded (labelSet: %s, global limit: %d actual local limit: %d)",
+		minNonZero(err.globalLimit, err.actualLocalLimit), err.id, err.globalLimit, err.actualLocalLimit)
 }
 
 func (l *Limiter) limitsPerLabelSets(userID string, metric labels.Labels) []validation.LimitsPerLabelSet {
Repository: getkin/kin-openapi (Go)

Issue:
date-time regex allows timezone offset to be missing
I'm using this library in tandem with oapi codegen. I am validating a request with `?start_time\=2024-10-22T00:00:00-04:00` as a query param. The validation works fine but I was experimenting and removed the timezone offset and sent `?start_time\=2024-10-22T00:00:00` and that seems to make it past the validation from kin openapi and doesn't make it past the codegen generated validation for date-time.

In their library they do 
```
// Time is a special case of a struct that we handle
			parsedTime, err := time.Parse(time.RFC3339Nano, src)
			if err != nil {
				parsedTime, err = time.Parse(types.DateFormat, src)
				if err != nil {
					return fmt.Errorf("error parsing '%s' as RFC3339 or 2006-01-02 time: %s", src, err)
				}
			}
```
time.Parse, so if I'm understanding this right, I think the regex needs to be strengthened to match that validation



Fix (patch):
diff --git a/.github/docs/openapi3.txt b/.github/docs/openapi3.txt
index 7d0fa449..7458a1b1 100644
--- a/.github/docs/openapi3.txt
+++ b/.github/docs/openapi3.txt
@@ -38,7 +38,7 @@ const (
 	FormatOfStringDate = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])$`
 
 	// FormatOfStringDateTime is a RFC3339 date-time format regexp, for example "2017-07-21T17:32:28Z".
-	FormatOfStringDateTime = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])T([0-1][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?(Z|(\+|-)[0-9]{2}:[0-9]{2})?$`
+	FormatOfStringDateTime = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])T([0-1][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?(Z|(\+|-)[0-9]{2}:[0-9]{2})$`
 )
 const (
 	SerializationSimple         = "simple"
diff --git a/openapi3/schema_formats.go b/openapi3/schema_formats.go
index 489105b4..da954dc5 100644
--- a/openapi3/schema_formats.go
+++ b/openapi3/schema_formats.go
@@ -44,7 +44,7 @@ const (
 	FormatOfStringDate = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])$`
 
 	// FormatOfStringDateTime is a RFC3339 date-time format regexp, for example "2017-07-21T17:32:28Z".
-	FormatOfStringDateTime = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])T([0-1][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?(Z|(\+|-)[0-9]{2}:[0-9]{2})?$`
+	FormatOfStringDateTime = `^[0-9]{4}-(0[1-9]|10|11|12)-(0[1-9]|[12][0-9]|3[01])T([0-1][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?(Z|(\+|-)[0-9]{2}:[0-9]{2})$`
 )
 
 func init() {
Repository: oapi-codegen/oapi-codegen (Go)

Issue:
Panic in fiber's server when registering handlers with middleware
Hi,

When using the `RegisterHandlersWithOptions` function with middleware, a panic occurs with the message "use: invalid handler". This happens when the middleware, defined as `MiddlewareFunc`, is passed to Fiber's `Use` method. The `Use` method does not recognize `MiddlewareFunc` as a `fiber.Handler`, even though `MiddlewareFunc` is a type alias for `fiber.Handler`.

This issue can be reproduced by trying to register middleware with a Fiber router using the `RegisterHandlersWithOptions` function.

Potential Solution:

The issue seems to be due to the missing type conversion when passing the middleware function to the `Use` method. To fix this, the [template](https://github.com/deepmap/oapi-codegen/blob/1da4d425142a282138411898172f29d31abb57aa/pkg/codegen/templates/fiber/fiber-handler.tmpl#L19C16-L19C17) used to generate the `RegisterHandlersWithOptions` function should be updated to include a type conversion for each middleware:

```go
for _, m := range options.Middlewares {
    router.Use(fiber.Handler(m))
}
```

This explicitly converts each `MiddlewareFunc` to a `fiber.Handler`, which should ensure it's recognized as such by `Use`. This change could be incorporated into the `RegisterHandlersWithOptions` function to support middleware.



Fix (patch):
diff --git a/examples/minimal-server/fiber/api/ping.gen.go b/examples/minimal-server/fiber/api/ping.gen.go
index 94c02016d..78e784bc9 100644
--- a/examples/minimal-server/fiber/api/ping.gen.go
+++ b/examples/minimal-server/fiber/api/ping.gen.go
@@ -50,7 +50,7 @@ func RegisterHandlersWithOptions(router fiber.Router, si ServerInterface, option
 	}
 
 	for _, m := range options.Middlewares {
-		router.Use(m)
+		router.Use(fiber.Handler(m))
 	}
 
 	router.Get(options.BaseURL+"/ping", wrapper.GetPing)
diff --git a/examples/petstore-expanded/fiber/api/petstore-server.gen.go b/examples/petstore-expanded/fiber/api/petstore-server.gen.go
index bb8538efd..b3fa4b968 100644
--- a/examples/petstore-expanded/fiber/api/petstore-server.gen.go
+++ b/examples/petstore-expanded/fiber/api/petstore-server.gen.go
@@ -127,7 +127,7 @@ func RegisterHandlersWithOptions(router fiber.Router, si ServerInterface, option
 	}
 
 	for _, m := range options.Middlewares {
-		router.Use(m)
+		router.Use(fiber.Handler(m))
 	}
 
 	router.Get(options.BaseURL+"/pets", wrapper.FindPets)
diff --git a/pkg/codegen/templates/fiber/fiber-handler.tmpl b/pkg/codegen/templates/fiber/fiber-handler.tmpl
index 4a55b3c51..7745e0d88 100644
--- a/pkg/codegen/templates/fiber/fiber-handler.tmpl
+++ b/pkg/codegen/templates/fiber/fiber-handler.tmpl
@@ -16,7 +16,7 @@ Handler: si,
 }
 
 for _, m := range options.Middlewares {
-    router.Use(m)
+    router.Use(fiber.Handler(m))
 }
 {{end}}
 {{range .}}
Repository: go-co-op/gocron (Go)

Issue:
[BUG] - Scheduler panics with unhelpful message if `StartBlocking` is called with zero jobs in the scheduler
### Describe the bug

<!---A clear and concise description of what the bug is.--->

When running `StartBlocking` with zero jobs in the scheduler a panic is raised with the message `fatal error: all goroutines are asleep - deadlock!`

### To Reproduce

```
package main

import (
	"time"

	"github.com/go-co-op/gocron"
)

func main() {
	s := gocron.NewScheduler(time.UTC)
	s.StartBlocking()
}
```

### Version

<!---The release version or commit SHA you're using.--->

<!---Have you tried the latest version?--->

`v1.28.0`

### Expected behavior

<!---A clear and concise description of what you expected to happen.--->

the panic should be meaningful so the user understands how to resolve

### Additional context

<!---Add any other context about the problem here.--->




Fix (patch):
diff --git a/scheduler.go b/scheduler.go
index 50fa7d10..72850f41 100644
--- a/scheduler.go
+++ b/scheduler.go
@@ -77,7 +77,12 @@ func (s *Scheduler) SetMaxConcurrentJobs(n int, mode limitMode) {
 
 // StartBlocking starts all jobs and blocks the current thread.
 // This blocking method can be stopped with Stop() from a separate goroutine.
+//
+// There must be at least 1 job in the scheduler or a panic will occur.
 func (s *Scheduler) StartBlocking() {
+	if len(s.Jobs()) == 0 {
+		panic("gocron: scheduler must have at least 1 job before calling StartBlocking")
+	}
 	s.StartAsync()
 	s.startBlockingStopChanMutex.Lock()
 	s.startBlockingStopChan = make(chan struct{}, 1)
Repository: go-co-op/gocron (Go)

Issue:
`.At()` without `.StartAt()` never fires
### Describe the bug

Calling `.At()` without calling `.StartAt()` results in jobs never running. Calling `.NextRun()` also yields values in the past, which is odd.

### To Reproduce

Run the following code.

```go
package main

import (
	"fmt"
	"log"
	"time"

	"github.com/go-co-op/gocron"
)

func main() {
	k := time.Now().Add(1 * time.Second)

	location, err := time.LoadLocation("EST")
	if err != nil {
		fmt.Println(err)
		return
	}

	s := gocron.NewScheduler(location)
	_, err = s.Every(1).Week().At(k).Do(func() {
		log.Println("Running scheduled function")
	})
	if err != nil {
		fmt.Println(err)
		return
	}

	s.StartAsync()

	time.Sleep(10 * time.Second)
}
```

### Version

v1.18.0

### Expected behavior

Since the job is scheduled weekly starting 1 second from now, it should fire once and then schedule for next week.

### Other

Possibly related to #399 


Discussion: Same here



Fix (patch):
diff --git a/scheduler.go b/scheduler.go
index a05d854b..758ba1fc 100644
--- a/scheduler.go
+++ b/scheduler.go
@@ -336,7 +336,22 @@ func (s *Scheduler) calculateWeekday(job *Job, lastRun time.Time) nextRun {
 
 func (s *Scheduler) calculateWeeks(job *Job, lastRun time.Time) nextRun {
 	totalDaysDifference := int(job.getInterval()) * 7
-	next := s.roundToMidnightAndAddDSTAware(lastRun, job.getFirstAtTime()).AddDate(0, 0, totalDaysDifference)
+
+	var next time.Time
+
+	atTimes := job.atTimes
+	for _, at := range atTimes {
+		n := s.roundToMidnightAndAddDSTAware(lastRun, at)
+		if n.After(s.now()) {
+			next = n
+			break
+		}
+	}
+
+	if next.IsZero() {
+		next = s.roundToMidnightAndAddDSTAware(lastRun, job.getFirstAtTime()).AddDate(0, 0, totalDaysDifference)
+	}
+
 	return nextRun{duration: until(lastRun, next), dateTime: next}
 }
Repository: vitessio/vitess (Go)

Issue:
Bug Report: vtcombo leaks connections on drop + create database
### Overview of the Issue

After executing `DROP DATABASE` followed by `CREATE DATABASE` several times queries will start to fail with "Too many connections" errors.

This is because the connection pools for each of the internal tablets are not closed on `DROP DATABASE` so they reconnect once the database exists again after the next `CREATE DATABASE`.

PR to fix this: https://github.com/vitessio/vitess/pull/16606

### Reproduction Steps

1. Start vtcombo via vttestserver
```
vttestserver --keyspaces foo --num_shards 1 --port 20040
```
2. Connect
```
mysql --host 127.0.0.1 --port 20043
```
3. Count connections
```
mysql> select db, user, count(*) from information_schema.PROCESSLIST group by db, user order by db, user;
+----------+-----------------+----------+
| db       | user            | count(*) |
+----------+-----------------+----------+
| NULL     | event_scheduler |        1 |
| vt_foo_0 | vt_allprivs     |        1 |
| vt_foo_0 | vt_dba          |        8 |
+----------+-----------------+----------+
```
4. Drop and create the database
```
mysql> drop database foo;
mysql> create database foo;
```
5. Count connections
```
mysql> select db, user, count(*) from information_schema.PROCESSLIST group by db, user order by db, user;
+----------+-----------------+----------+
| db       | user            | count(*) |
+----------+-----------------+----------+
| NULL     | event_scheduler |        1 |
| vt_foo_0 | vt_allprivs     |        2 |
| vt_foo_0 | vt_dba          |       13 |
+----------+-----------------+----------+
```


### Binary Version

```sh
Impacts main and previous versions
```


### Operating System and Environment details

```sh
n/a
```


### Log Fragments

_No response_



Fix (patch):
diff --git a/go/vt/vtcombo/tablet_map.go b/go/vt/vtcombo/tablet_map.go
index 77b7446fc1d..88b09846edd 100644
--- a/go/vt/vtcombo/tablet_map.go
+++ b/go/vt/vtcombo/tablet_map.go
@@ -254,7 +254,11 @@ func DeleteKs(
 			tablet.tm.Stop()
 			tablet.tm.Close()
 			tablet.qsc.SchemaEngine().Close()
-			err := ts.DeleteTablet(ctx, tablet.alias)
+			err := tablet.qsc.QueryService().Close(ctx)
+			if err != nil {
+				return err
+			}
+			err = ts.DeleteTablet(ctx, tablet.alias)
 			if err != nil {
 				return err
 			}
Repository: googleapis/genai-toolbox (Go)

Issue:
Add support for `--tools-file` alias
I often find myself tripping up and attempting to launch Toolbox with the `--tools-file` flag.

The actual flag is `--tools_file` using an underscore... yet all other flags do not use this pattern.

https://github.com/googleapis/genai-toolbox/blob/64da5b4efe7d948ceb366c37fdaabd42405bc932/cmd/root.go#L108

Adding an alias for `--tools-file` is probably the best path forward to consolidate flag naming pattern without introducing a breaking change.

 



Fix (patch):
diff --git a/cmd/root.go b/cmd/root.go
index a0fb90abfbb..d4b88a3a753 100644
--- a/cmd/root.go
+++ b/cmd/root.go
@@ -106,6 +106,9 @@ func NewCommand(opts ...Option) *Command {
 	flags.IntVarP(&cmd.cfg.Port, "port", "p", 5000, "Port the server will listen on.")
 
 	flags.StringVar(&cmd.tools_file, "tools_file", "tools.yaml", "File path specifying the tool configuration.")
+	// deprecate tools_file
+	_ = flags.MarkDeprecated("tools_file", "please use --tools-file instead")
+	flags.StringVar(&cmd.tools_file, "tools-file", "tools.yaml", "File path specifying the tool configuration.")
 	flags.Var(&cmd.cfg.LogLevel, "log-level", "Specify the minimum level logged. Allowed: 'DEBUG', 'INFO', 'WARN', 'ERROR'.")
 	flags.Var(&cmd.cfg.LoggingFormat, "logging-format", "Specify logging format to use. Allowed: 'standard' or 'JSON'.")
 	flags.BoolVar(&cmd.cfg.TelemetryGCP, "telemetry-gcp", false, "Enable exporting directly to Google Cloud Monitoring.")