[logger] Implement Database.Trace so SQL trace logging is not swallowed

[Atishyy27]

Notes for Reviewers

• This PR fixes logger: Database.Trace() is a no output — SQL trace logging silently swallowed #1063

Database.Trace() in logger/database.go had an empty body, so everything GORM handed it after each SQL statement (the statement itself, execution time, row count, and any error) was silently dropped. Info, Warn and Error in the same file all forward to the underlying logger, Trace was the odd one out.

what changed

Trace now forwards to the logger the way its neighbours do: errors go to the error handler, everything else to the default handler. The message format matches GORM's own logger ([%.3fms] [rows:%v] %s), including its convention of reporting a row count of -1 as a dash when a count does not apply to the statement. I mirrored the existing format rather than inventing one so output stays consistent with what GORM users already read.

before

(nothing, for every query)

after

[1.204ms] [rows:3] SELECT * FROM meshery_patterns
no such table: missing_table [0.881ms] [rows:0] SELECT * FROM missing_table

tests

Added TestDatabase_Trace covering a successful query, a failed query (asserting it reaches the error handler with the error), and the rows:-1 case. Verified it fails before the change (every assertion sees an empty buffer) and passes after.

go test --short -count=1 ./logger/
ok  	github.com/meshery/meshkit/logger	2.258s

gofmt and go vet are clean on the touched files.

Signed commits

• Yes, I signed my commits.

[gemini-code-assist]

Code Review

This pull request implements the Trace method for the GORM database logger in logger/database.go to log SQL execution details, and introduces a comprehensive test suite in logger/database_test.go. The review feedback recommends adding defensive nil checks for the logger receiver, its base, and the callback function fc to prevent potential nil pointer dereferences and panics.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To prevent potential nil pointer dereferences and panics, add defensive checks to ensure that c, c.base, and the fc function are not nil before executing them.

Suggested change

	sql, rows := fc()
	if c == nil || c.base == nil || fc == nil {
	return
	}
	sql, rows := fc()

[Atishyy27]

good catch, added. guarded against a nil receiver, nil base, and nil fc, one line at the top
of Trace. covered by TestDatabase_Trace_NilReceiverAndArgs, which panics without the guard and
passes with it. pushed in 1dbe409

[ritzorama]

Is this Opentracing compatible?

[ritzorama]

Let's use Opentracing for this functionality...

[Atishyy27]

Thanks for taking a look! I think there's a mix-up on what this Trace is. It isn't distributed tracing - it's the Trace method on GORM's logger interface (gorm.io/gorm/logger.Interface), which the Database logger has to implement. GORM calls it after every SQL statement with the query, timing, row count, and any error, purely for logging. Ours had an empty body, so all of
that was being silently dropped while Info/Warn/Error forwarded correctly - this PR just makes Trace consistent with them.

[ishwar170695]

Looks good to me. This fixes the missing Trace implementation with a minimal, targeted change, follows the existing logger conventions, and includes good test coverage for the expected paths and nil guards. Thanks!