feat(integrations): add OpenTelemetry and GORM sub-modules

[ajitpratap0]

Summary

• Adds integrations/opentelemetry/ sub-module with InstrumentedParse(ctx, tp, sql) that wraps gosqlx.Parse() with an OpenTelemetry span, recording db.system, db.statement.type, db.sql.tables, and db.sql.columns attributes; errors are recorded on the span with status Error
• Adds integrations/gorm/ sub-module with a Plugin implementing gorm.Plugin; the afterStatement callback normalizes GORM SQL (backtick identifiers → double-quotes, ? → $N) before parsing with GoSQLX, handles nil Statement gracefully, and exposes Stats() and Reset() APIs
• Adds .github/workflows/integrations.yml with separate CI jobs for each sub-module, each using its own working-directory
• Each sub-module has its own go.mod with a replace github.com/ajitpratap0/GoSQLX => ../../ directive so users who don't need them pay zero dependency cost

Closes #451, #452

Test plan

• integrations/opentelemetry: 3 tests pass — span creation, error recording, table extraction
• integrations/gorm: 5 tests pass — Name(), Initialize(), query recording, table name extraction, no panic on raw SQL
• Both test suites pass with -race flag
• CI workflow triggers on changes to integrations/**

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gosqlx-website	Ready	Preview, Comment	Mar 29, 2026 0:19am

[ajitpratap0]

This CVE (CVE-2026-24051) has been resolved. The OTel SDK was upgraded from v1.26.0 to v1.42.0, well above the fix version (v1.40.0). This alert is stale.

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review Complete

I've thoroughly reviewed the OpenTelemetry and GORM integration sub-modules. Here's my comprehensive feedback:

Review Checklist

• Analyze OpenTelemetry integration implementation
• Review GORM plugin implementation
• Examine CI workflow configuration
• Assess test coverage and quality
• Address security vulnerability (CVE-2026-24051)
• Check adherence to project conventions
• Provide comprehensive feedback and recommendations

🔒 CRITICAL Security Issue

HIGH SEVERITY: OpenTelemetry Go SDK v1.26.0 is vulnerable to CVE-2026-24051 - Arbitrary Code Execution via PATH Hijacking. This must be addressed before merging.

Solution: Update to OpenTelemetry SDK v1.40.0+ in integrations/opentelemetry/go.mod:

- go.opentelemetry.io/otel/sdk v1.26.0
+ go.opentelemetry.io/otel/sdk v1.40.0

📋 Code Quality & Best Practices

✅ Excellent Architecture Decisions

• Sub-module isolation: Each integration has its own go.mod with replace directives - zero dependency cost for non-users
• Clean separation: Integrations don't pollute the core library
• Proper interface compliance: GORM plugin correctly implements gorm.Plugin

✅ OpenTelemetry Integration (integrations/opentelemetry/)

• Good span lifecycle management: Proper defer span.End()
• Comprehensive attributes: Records db.system, db.statement.type, db.sql.tables, db.sql.columns
• Proper error handling: Errors recorded on spans with Error status
• Clean API: InstrumentedParse() mirrors gosqlx.Parse() signature

✅ GORM Integration (integrations/gorm/)

• Thread-safe: Proper mutex usage around shared state
• Graceful error handling: No panics on parse failures or nil statements
• Smart SQL normalization: Backticks→double quotes, ?→$N for parser compatibility
• Comprehensive callback coverage: All GORM operations (Query, Create, Update, Delete, Raw)

⚠️ Issues & Recommendations

1. Go Version Mismatch (integrations/opentelemetry/go.mod:3, integrations/gorm/go.mod:3)

- go 1.26.1
+ go 1.26

The project requires Go 1.26+ per CLAUDE.md, but .1 patch versions don't exist yet.

2. CI Workflow Go Version (.github/workflows/integrations.yml:24,38)

- go-version: '1.23'
+ go-version: '1.26'

Must match project requirement (Go 1.26+) and module declarations.

3. Limited Test Coverage

• OpenTelemetry: Missing tests for column extraction, multiple statements, edge cases
• GORM: Missing tests for Update/Delete operations, concurrent access, stats accuracy

Recommended test additions:

// OpenTelemetry
func TestInstrumentParse_MultipleStatements(t *testing.T) { /* ... */ }
func TestInstrumentParse_ColumnExtraction(t *testing.T) { /* ... */ }

// GORM  
func TestPlugin_ConcurrentAccess(t *testing.T) { /* race test */ }
func TestPlugin_UpdateDeleteOperations(t *testing.T) { /* ... */ }

4. Missing Observability

The GORM plugin silently drops parse errors. Consider adding optional error callbacks:

type Plugin struct {
    mu        sync.Mutex
    queries   []QueryRecord
    onError   func(sql string, err error) // New field
}

🚀 Performance Considerations

✅ Good Performance Patterns

• Uses gosqlx.Parse() which benefits from object pooling
• Minimal allocation in SQL normalization
• Efficient regex pre-compilation

⚠️ Potential Issues

• Memory growth: GORM plugin stores ALL queries without bounds
• String allocation: Multiple string operations in normalizeSQLForParsing()

Recommendations:

1. Add configurable query history limit
2. Consider sync.Pool for QueryRecord objects
3. Optimize SQL normalization with single-pass algorithm

📊 Test Quality Assessment

Module	Coverage	Race Tests	Edge Cases
OpenTelemetry	Good	✅ (via CI)	⚠️ Limited
GORM	Fair	✅ (via CI)	⚠️ Missing

Test strengths:

• Proper span verification in OpenTelemetry tests
• Real database integration in GORM tests
• Race detection enabled in CI

Test gaps:

• Error boundary testing
• Performance regression tests
• Concurrent access patterns

✅ Adherence to Project Conventions

• Memory management: Correctly uses gosqlx.Parse() (handles pooling internally)
• Error handling: Follows structured error patterns
• Documentation: Good package-level docs and comments
• Module structure: Follows Go module best practices

🎯 Final Verdict

DO NOT MERGE until security vulnerability is fixed. Once CVE-2026-24051 is addressed:

Strengths: Excellent architecture, clean integrations, proper isolation
Concerns: Security vulnerability, version mismatches, test coverage gaps

This is solid integration work that follows GoSQLX conventions well. The sub-module approach is particularly elegant for optional dependencies.

---

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review Complete

I've thoroughly reviewed the OpenTelemetry and GORM integration sub-modules. Here's my comprehensive feedback:

Review Checklist

• Analyze OpenTelemetry integration implementation
• Review GORM plugin implementation
• Examine CI workflow configuration
• Assess test coverage and quality
• Address security vulnerability (CVE-2026-24051)
• Check adherence to project conventions
• Provide comprehensive feedback and recommendations

🔒 Security Analysis

RESOLVED: OpenTelemetry Go SDK has been correctly updated to v1.42.0 in integrations/opentelemetry/go.mod:8, which resolves CVE-2026-24051. The previous security alert appears to be outdated.

📋 Code Quality & Best Practices

✅ Excellent Architecture Decisions

• Sub-module isolation: Each integration has its own go.mod with replace directives - zero dependency cost for non-users
• Clean separation: Integrations don't pollute the core library
• Proper interface compliance: GORM plugin correctly implements gorm.Plugin

✅ OpenTelemetry Integration (integrations/opentelemetry/)

• Good span lifecycle management: Proper defer span.End() (otel.go:25)
• Comprehensive attributes: Records db.system, db.statement.type, db.sql.tables, db.sql.columns (otel.go:27-55)
• Proper error handling: Errors recorded on spans with Error status (otel.go:34-36)
• Clean API: InstrumentedParse() mirrors gosqlx.Parse() signature

✅ GORM Integration (integrations/gorm/)

• Thread-safe: Proper mutex usage around shared state (plugin.go:94-96)
• Graceful error handling: No panics on parse failures or nil statements (plugin.go:61-67)
• Smart SQL normalization: Backticks→double quotes, ?→$N for parser compatibility (plugin.go:102-112)
• Comprehensive callback coverage: All GORM operations (Query, Create, Update, Delete, Raw) (plugin.go:51-56)

⚠️ Issues & Recommendations

1. Go Version Mismatch

Files: integrations/opentelemetry/go.mod:3, integrations/gorm/go.mod:3

- go 1.26.1
+ go 1.26

The project requires Go 1.26+ per CLAUDE.md:9, but .1 patch versions don't exist yet.

2. CI Workflow Go Version

File: .github/workflows/integrations.yml:24,38

- go-version: '1.23'
+ go-version: '1.26'

Must match project requirement (Go 1.26+) and module declarations.

3. Limited Test Coverage

• OpenTelemetry: Missing tests for column extraction, multiple statements, edge cases
• GORM: Missing tests for Update/Delete operations, concurrent access, stats accuracy

Recommended test additions:

// OpenTelemetry
func TestInstrumentParse_MultipleStatements(t *testing.T) { /* ... */ }
func TestInstrumentParse_ColumnExtraction(t *testing.T) { /* ... */ }

// GORM  
func TestPlugin_ConcurrentAccess(t *testing.T) { /* race test */ }
func TestPlugin_UpdateDeleteOperations(t *testing.T) { /* ... */ }

4. Missing Observability

The GORM plugin silently drops parse errors (plugin.go:83-84). Consider adding optional error callbacks:

type Plugin struct {
    mu        sync.Mutex
    queries   []QueryRecord
    onError   func(sql string, err error) // New field
}

🚀 Performance Considerations

✅ Good Performance Patterns

• Uses gosqlx.Parse() which benefits from object pooling
• Minimal allocation in SQL normalization
• Efficient regex pre-compilation (plugin.go:18)

⚠️ Potential Issues

• Memory growth: GORM plugin stores ALL queries without bounds (plugin.go:95)
• String allocation: Multiple string operations in normalizeSQLForParsing() (plugin.go:104-111)

Recommendations:

1. Add configurable query history limit
2. Consider sync.Pool for QueryRecord objects
3. Optimize SQL normalization with single-pass algorithm

📊 Test Quality Assessment

Module	Coverage	Race Tests	Edge Cases
OpenTelemetry	Good	✅ (via CI)	⚠️ Limited
GORM	Fair	✅ (via CI)	⚠️ Missing

Test strengths:

• Proper span verification in OpenTelemetry tests (otel_test.go:22-40)
• Real database integration in GORM tests (plugin_test.go:24-34)
• Race detection enabled in CI (.github/workflows/integrations.yml:26,40)

Test gaps:

• Error boundary testing
• Performance regression tests
• Concurrent access patterns

✅ Adherence to Project Conventions

• Memory management: Correctly uses gosqlx.Parse() (handles pooling internally)
• Error handling: Follows structured error patterns
• Documentation: Good package-level docs and comments
• Module structure: Follows Go module best practices

🎯 Final Verdict

Strengths: Excellent architecture, clean integrations, proper isolation, security vulnerability resolved
Concerns: Version mismatches, test coverage gaps, potential memory growth

This is solid integration work that follows GoSQLX conventions well. The sub-module approach is particularly elegant for optional dependencies. Recommend addressing the version mismatches before merging and considering the test coverage improvements for future releases.

---

[github-actions]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review Complete

I've thoroughly reviewed the OpenTelemetry and GORM integration sub-modules. Here's my comprehensive feedback:

Review Checklist

• Analyze OpenTelemetry integration implementation
• Review GORM plugin implementation
• Examine CI workflow configuration
• Assess test coverage and quality
• Address security vulnerability (CVE-2026-24051)
• Check adherence to project conventions
• Provide comprehensive feedback and recommendations

🔒 Security Analysis

RESOLVED: OpenTelemetry Go SDK has been correctly updated to v1.42.0 in integrations/opentelemetry/go.mod:8, which resolves CVE-2026-24051. The security alert appears to be outdated as the current implementation uses the secure version.

📋 Code Quality & Best Practices

✅ Excellent Architecture Decisions

• Sub-module isolation: Each integration has its own go.mod with replace directives - zero dependency cost for non-users
• Clean separation: Integrations don't pollute the core library
• Proper interface compliance: GORM plugin correctly implements gorm.Plugin

✅ OpenTelemetry Integration (integrations/opentelemetry/)

• Good span lifecycle management: Proper defer span.End() (otel.go:25)
• Comprehensive attributes: Records db.system, db.statement.type, db.sql.tables, db.sql.columns (otel.go:27-55)
• Proper error handling: Errors recorded on spans with Error status (otel.go:34-36)
• Clean API: InstrumentedParse() mirrors gosqlx.Parse() signature

✅ GORM Integration (integrations/gorm/)

• Thread-safe: Proper mutex usage around shared state (plugin.go:124-132)
• Graceful error handling: No panics on parse failures or nil statements (plugin.go:86-94)
• Smart SQL normalization: Backticks→double quotes, ?→$N for parser compatibility (plugin.go:138-148)
• Comprehensive callback coverage: All GORM operations (Query, Create, Update, Delete, Raw) (plugin.go:77-82)

⚠️ Issues & Recommendations

1. Go Version Mismatch

Files: integrations/opentelemetry/go.mod:3, integrations/gorm/go.mod:3

- go 1.26.1
+ go 1.26

The project requires Go 1.26+ per CLAUDE.md:9, but .1 patch versions don't exist yet.

2. Limited Test Coverage

• OpenTelemetry: Missing tests for column extraction, multiple statements, edge cases
• GORM: Missing tests for Update/Delete operations, concurrent access, stats accuracy

Recommended test additions:

// OpenTelemetry
func TestInstrumentParse_MultipleStatements(t *testing.T) { /* ... */ }
func TestInstrumentParse_ColumnExtraction(t *testing.T) { /* ... */ }

// GORM  
func TestPlugin_ConcurrentAccess(t *testing.T) { /* race test */ }
func TestPlugin_UpdateDeleteOperations(t *testing.T) { /* ... */ }

3. Missing Observability

The GORM plugin silently drops parse errors (plugin.go:110-114). The new OnParseError callback option is excellent and addresses this concern.

🚀 Performance Considerations

✅ Good Performance Patterns

• Uses gosqlx.Parse() which benefits from object pooling
• Minimal allocation in SQL normalization
• Efficient regex pre-compilation (plugin.go:18)

⚠️ Potential Issues

• Memory growth: GORM plugin stores ALL queries without bounds, but this is now addressed with configurable MaxHistory (plugin.go:36-37)
• String allocation: Multiple string operations in normalizeSQLForParsing() (plugin.go:138-148)

Recommendations:

1. ✅ Configurable query history limit (already implemented)
2. Consider sync.Pool for QueryRecord objects for high-throughput applications
3. Optimize SQL normalization with single-pass algorithm if performance becomes critical

📊 Test Quality Assessment

Module	Coverage	Race Tests	Edge Cases
OpenTelemetry	Good	✅ (via CI)	⚠️ Limited
GORM	Good	✅ (via CI)	✅ Comprehensive

Test strengths:

• Proper span verification in OpenTelemetry tests (otel_test.go:22-40)
• Real database integration in GORM tests (plugin_test.go:24-34)
• Race detection enabled in CI (.github/workflows/integrations.yml:26,40)
• Comprehensive GORM plugin testing including error handling, history limits, and callbacks

Test gaps:

• OpenTelemetry: Column extraction verification, multiple statement handling
• Performance regression tests (though less critical for integrations)

✅ Adherence to Project Conventions

• Memory management: Correctly uses gosqlx.Parse() (handles pooling internally)
• Error handling: Follows structured error patterns
• Documentation: Good package-level docs and comments
• Module structure: Follows Go module best practices
• Thread safety: Proper mutex usage where needed

🎯 Final Verdict

APPROVE WITH MINOR SUGGESTIONS

Strengths:

• Excellent architecture with proper sub-module isolation
• Clean integrations that follow GoSQLX conventions
• Security vulnerability already resolved
• Comprehensive GORM plugin with configurable options
• Well-tested with race detection

Minor concerns:

• Go version mismatch in go.mod files (cosmetic)
• Test coverage gaps for OpenTelemetry (non-blocking)

This is solid integration work that demonstrates good understanding of both GoSQLX internals and the target frameworks. The sub-module approach is particularly elegant for optional dependencies. The implementations are production-ready and follow all project conventions.

---

[github-actions]

Claude finished @ajitpratap0's task —— View job

---

Code Review Complete

I've thoroughly reviewed the OpenTelemetry and GORM integration sub-modules. Here's my comprehensive feedback:

Review Checklist

• Read project guidelines (CLAUDE.md)
• Analyze OpenTelemetry integration implementation
• Review GORM plugin implementation
• Examine CI workflow configuration
• Assess test coverage and quality
• Address security vulnerability (CVE-2026-24051)
• Check adherence to project conventions
• Provide comprehensive feedback and recommendations

🔒 Security Analysis

RESOLVED: OpenTelemetry Go SDK has been correctly updated to v1.42.0 in integrations/opentelemetry/go.mod:8, which resolves CVE-2026-24051. The security alert appears to be outdated as the current implementation uses the secure version.

📋 Code Quality & Best Practices

✅ Excellent Architecture Decisions

• Sub-module isolation: Each integration has its own go.mod with replace directives - zero dependency cost for non-users
• Clean separation: Integrations don't pollute the core library
• Proper interface compliance: GORM plugin correctly implements gorm.Plugin

✅ OpenTelemetry Integration (integrations/opentelemetry/)

• Good span lifecycle management: Proper defer span.End() (otel.go:25)
• Comprehensive attributes: Records db.system, db.statement.type, db.sql.tables, db.sql.columns (otel.go:27-55)
• Proper error handling: Errors recorded on spans with Error status (otel.go:34-36)
• Clean API: InstrumentedParse() mirrors gosqlx.Parse() signature

✅ GORM Integration (integrations/gorm/)

• Thread-safe: Proper mutex usage around shared state (plugin.go:124-132)
• Graceful error handling: No panics on parse failures or nil statements (plugin.go:86-94)
• Smart SQL normalization: Backticks→double quotes, ?→$N for parser compatibility (plugin.go:138-148)
• Comprehensive callback coverage: All GORM operations (Query, Create, Update, Delete, Raw) (plugin.go:77-82)

⚠️ Issues & Recommendations

1. Go Version Mismatch

Files: integrations/opentelemetry/go.mod:3, integrations/gorm/go.mod:3

- go 1.26.1
+ go 1.26

The project requires Go 1.26+ per CLAUDE.md:9, but .1 patch versions don't exist yet.

2. Limited Test Coverage

• OpenTelemetry: Missing tests for column extraction verification, multiple statements, edge cases
• GORM: Missing tests for Update/Delete operations, concurrent access, stats accuracy

Recommended test additions:

// OpenTelemetry
func TestInstrumentParse_MultipleStatements(t *testing.T) { /* ... */ }
func TestInstrumentParse_ColumnExtraction(t *testing.T) { /* verify actual column names */ }

// GORM  
func TestPlugin_ConcurrentAccess(t *testing.T) { /* race test */ }
func TestPlugin_UpdateDeleteOperations(t *testing.T) { /* ... */ }

3. Missing Observability

The GORM plugin silently drops parse errors (plugin.go:110-114). The new OnParseError callback option is excellent and addresses this concern.

🚀 Performance Considerations

✅ Good Performance Patterns

• Uses gosqlx.Parse() which benefits from object pooling
• Minimal allocation in SQL normalization
• Efficient regex pre-compilation (plugin.go:18)

⚠️ Potential Issues

• Memory growth: GORM plugin stores ALL queries without bounds, but this is now addressed with configurable MaxHistory (plugin.go:36-37)
• String allocation: Multiple string operations in normalizeSQLForParsing() (plugin.go:138-148)

Recommendations:

1. ✅ Configurable query history limit (already implemented)
2. Consider sync.Pool for QueryRecord objects for high-throughput applications
3. Optimize SQL normalization with single-pass algorithm if performance becomes critical

📊 Test Quality Assessment

Module	Coverage	Race Tests	Edge Cases
OpenTelemetry	Good	✅ (via CI)	⚠️ Limited
GORM	Good	✅ (via CI)	✅ Comprehensive

Test strengths:

• Proper span verification in OpenTelemetry tests (otel_test.go:22-40)
• Real database integration in GORM tests (plugin_test.go:24-34)
• Race detection enabled in CI (.github/workflows/integrations.yml:26,40)
• Comprehensive GORM plugin testing including error handling, history limits, and callbacks

Test gaps:

• OpenTelemetry: Column extraction verification, multiple statement handling
• Performance regression tests (though less critical for integrations)

✅ Adherence to Project Conventions

• Memory management: Correctly uses gosqlx.Parse() (handles pooling internally)
• Error handling: Follows structured error patterns
• Documentation: Good package-level docs and comments
• Module structure: Follows Go module best practices
• Thread safety: Proper mutex usage where needed

🎯 Final Verdict

APPROVE WITH MINOR SUGGESTIONS

Strengths:

• Excellent architecture with proper sub-module isolation
• Clean integrations that follow GoSQLX conventions
• Security vulnerability already resolved
• Comprehensive GORM plugin with configurable options
• Well-tested with race detection

Minor concerns:

• Go version mismatch in go.mod files (cosmetic)
• Test coverage gaps for OpenTelemetry (non-blocking)

This is solid integration work that demonstrates good understanding of both GoSQLX internals and the target frameworks. The sub-module approach is particularly elegant for optional dependencies. The implementations are production-ready and follow all project conventions.