feat: PostgreSQL support for DomainAudit

[joannalauu]

What changed?
Implement SQL plugin interface and add PostgreSQL support for DomainAudit.

• Created domain_audit_log table in Postgresql schema
• Created data structures for DomainAuditLogRow and DomainAuditLogFilter in sqlplugin
• Implemented sqlplugin interfaces for InsertIntoDomainAuditLog and SelectFromDomainAuditLogs functions
• Implemented InsertIntoDomainAuditLog and SelectFromDomainAuditLogs functions in Postgresql
• Updated SQL factory to create newSQLDomainAuditStore

Fixes: #7602

Why?
DomainAudit allows all modifications made to a domain (e.g failovers) to be stored and retrieved. This has previously only been supported by NoSQL databases (Cassandra, MongoDB, DynamoDB). The SQL plugin is now configured to handle DomainAudit requests, so other SQL databases can also be easily configured to support DomainAudit. PostgreSQL support for DomainAudit is now added.

How did you test it?

• Unit tests: go test -v ./common/persistence/sql -run TestCreateDomainAuditLog TestGetDomainAuditLogs TestFactoryNewDomainAuditStore TestInsertIntoDomainAuditLog TestSelectFromDomainAuditLogs TestGetDataBlobEncoding TestGetDataBlobBytes
• Integration tests: Ran TestPostgresSQLDomainAuditPersistence on github actions

Potential risks

• Postgresql schema is updated with a new table; it can be rolled back with Postgres database release version

Release notes
Added PostgreSQL support for DomainAudit

Documentation Changes
N/A

---

Potential Breaking change

Detailed Description
[In-depth description of the changes made to the schema or interfaces, specifying new fields, removed fields, or modified data structures]

• Created domain_audit_log table in Postgresql schema
• Created data structures for DomainAuditLogRow and DomainAuditLogFilter in sqlplugin
• Implemented sqlplugin interfaces for InsertIntoDomainAuditLog and SelectFromDomainAuditLogs functions
• Implemented InsertIntoDomainAuditLog and SelectFromDomainAuditLogs functions in Postgresql
• Updated SQL factory to create newSQLDomainAuditStore

Impact Analysis

• Backward Compatibility: Schema changes can be rolled back with Postgres database release version
• Forward Compatibility: Doesn't affect existing schema

Testing Plan

• Unit Tests: go test -v ./common/persistence/sql -run TestCreateDomainAuditLog TestGetDomainAuditLogs TestFactoryNewDomainAuditStore TestInsertIntoDomainAuditLog TestSelectFromDomainAuditLogs TestGetDataBlobEncoding TestGetDataBlobBytes
• Persistence Tests: Ran TestPostgresSQLDomainAuditPersistence on github actions
• Integration Tests: [Do we have integration test covering the change?]
• Compatibility Tests: [Have we done tests to test the backward and forward compatibility?]

Rollout Plan

• What is the rollout plan?
• Does the order of deployment matter?
• Is it safe to rollback? Does the order of rollback matter? Schema changes can be rolled back with Postgres database release version
• Is there a kill switch to mitigate the impact immediately? Changing NewDomainAuditStore() to return nil, nil should revert effects of all changes

---

Reviewer Validation

PR Description Quality (check these before reviewing code):

• "What changed" provides a clear 1-2 line summary
  • Project Issue is linked
• "Why" explains the full motivation with sufficient context
• Testing is documented:
  • Unit test commands are included (with exact go test invocation)
  • Integration test setup/commands included (if integration tests were run)
  • Canary testing details included (if canary was mentioned)
• Potential risks section is thoughtfully filled out (or legitimately N/A)
• Release notes included if this completes a user-facing feature
• Documentation needs are addressed (or noted if uncertain)

[gitar-bot]

⚠️ Quality: MySQL domain audit log methods silently return nil

Details

The MySQL implementation of InsertIntoDomainAuditLog and SelectFromDomainAuditLogs returns nil, nil without any error, which silently fails. This could lead to data loss since callers would believe the operation succeeded when in fact no data was persisted.

Impact: If MySQL is used as the persistence layer and domain audit logs are enabled, the caller will think the audit log was created successfully, but no data will be stored. This is a silent failure mode that could go undetected in production.

Suggested fix: Return an appropriate error indicating the feature is not yet implemented:

func (mdb *DB) InsertIntoDomainAuditLog(ctx context.Context, row *sqlplugin.DomainAuditLogRow) (sql.Result, error) {
    return nil, fmt.Errorf("domain audit log is not implemented for MySQL")
}

func (mdb *DB) SelectFromDomainAuditLogs(ctx context.Context, filter *sqlplugin.DomainAuditLogFilter) ([]*sqlplugin.DomainAuditLogRow, error) {
    return nil, fmt.Errorf("domain audit log is not implemented for MySQL")
}

Alternatively, consider adding a feature flag or capability check that allows callers to verify if domain audit is supported by the persistence layer.

---

Was this helpful? React with 👍 / 👎

[joannalauu]

MySQL support is not part of this PR; these functions need to be implemented to pass interface checks

[gitar-bot]

🔍 CI failure analysis for af86213: Good news: PostgreSQL integration tests now passing after UUID→BYTEA fix! Only remaining failure is the missing breaking change template in PR description.

Status Update for Commit af86213

PostgreSQL Integration Tests: ✅ SUCCESS

The PostgreSQL integration tests (job 62164863742) have completed successfully! This is a significant improvement from earlier test runs. The schema change from UUID to BYTEA for domain_id and event_id appears to have resolved the integration test issues.

Previous Issue Resolution:
Earlier runs failed with UTF-8 encoding errors like:

• pq: invalid byte sequence for encoding "UTF8": 0xf9
• pq: invalid byte sequence for encoding "UTF8": 0x81

These errors are no longer occurring, indicating the UUID→BYTEA conversion properly handles the binary UUID data.

Remaining Issue: Breaking Change Template

The only CI failure is the breaking-change-pr-template-reminder (Workflow ID: 21576501324). The PR description still lacks required sections:

1. Detailed Description - Not found
2. Impact Analysis - Not found
3. Testing Plan - Not found
4. Rollout Plan - Not found

Details

All other CI checks have passed:

• ✅ CI Checks (all integration tests)
• ✅ Golang integration test with postgres
• ✅ Docker Build & Push
• ✅ Codecov integration
• ✅ Replication Simulation
• ✅ Semantic Pull Request
• ❌ Workflow for Breaking Change Reminder (requires PR description update)

Note: Job ID 62164863807 mentioned in the prompt does not exist. The actual postgres integration test job ID is 62164863742 and it passed successfully.

Code Review ⚠️ Changes requested 0 resolved / 3 findings

Good PostgreSQL implementation for DomainAudit with comprehensive tests. Previous findings remain: MySQL stubs silently return nil (potential silent failures), inconsistent time calculation in postgres, and manifest uses CQL terminology for SQL files.

⚠️ Quality: MySQL domain audit log methods silently return nil

📄 common/persistence/sql/sqlplugin/mysql/domain_audit_log.go:30-43

The MySQL implementation of InsertIntoDomainAuditLog and SelectFromDomainAuditLogs returns nil, nil without any error, which silently fails. This could lead to data loss since callers would believe the operation succeeded when in fact no data was persisted.

Impact: If MySQL is used as the persistence layer and domain audit logs are enabled, the caller will think the audit log was created successfully, but no data will be stored. This is a silent failure mode that could go undetected in production.

Suggested fix: Return an appropriate error indicating the feature is not yet implemented:

func (mdb *DB) InsertIntoDomainAuditLog(ctx context.Context, row *sqlplugin.DomainAuditLogRow) (sql.Result, error) {
    return nil, fmt.Errorf("domain audit log is not implemented for MySQL")
}

func (mdb *DB) SelectFromDomainAuditLogs(ctx context.Context, filter *sqlplugin.DomainAuditLogFilter) ([]*sqlplugin.DomainAuditLogRow, error) {
    return nil, fmt.Errorf("domain audit log is not implemented for MySQL")
}

Alternatively, consider adding a feature flag or capability check that allows callers to verify if domain audit is supported by the persistence layer.

💡 Quality: Manifest uses incorrect key name "SchemaUpdateCqlFiles"

📄 schema/postgres/cadence/versioned/v0.7/manifest.json:5

The manifest.json file uses "SchemaUpdateCqlFiles" as the key for listing SQL files. While "CQL" refers to Cassandra Query Language (NoSQL), this is a PostgreSQL (SQL) schema file. The naming is inconsistent and misleading.

Impact: This is primarily a naming/documentation issue. The key name appears to be reused from Cassandra schema versioning and may confuse maintainers. It might work if the schema tooling doesn't validate the key name, but it's technically incorrect terminology for SQL.

Suggested fix: If the schema tooling supports it, consider using a more appropriate key name like "SchemaUpdateSqlFiles" for SQL databases. If this key name is required by the existing schema migration tooling for consistency, consider adding a comment or updating the tooling documentation.

💡 Bug: Inconsistent default time calculation for `end` time

📄 common/persistence/sql/sqlplugin/postgres/domain_audit_log.go:64-65

The default end time is calculated using time.Unix(0, time.Now().UnixNano()) which is equivalent to just time.Now(). However, the default start time is time.Unix(0, 0) (Unix epoch).

Issue: While this works, the code is unnecessarily complex and could be simplified. More importantly, since created_time < $4 is used (exclusive), if a caller doesn't provide a MaxCreatedTime and wants to include all records up to now, they could miss records created at exactly the same nanosecond the query is executed (though this is extremely rare).

Suggested fix: For clarity and consistency, simplify to:

start := time.Time{} // zero time 
end := time.Now().Add(time.Minute) // slight buffer to ensure "now" records are included

if filter.MinCreatedTime != nil {
    start = *filter.MinCreatedTime
}
if filter.MaxCreatedTime != nil {
    end = *filter.MaxCreatedTime
}

Or consider using <= instead of < for the upper bound comparison in the query.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}