feat: Add SQLite support for domain audit

[joannalauu]

What changed?
Added SQLite support for DomainAudit.

• Created domain_audit_log table in SQLite schema
• Updated the sql_doamin_audit_store and the domain_audit_log tables for PostgreSQL and MySQL to accept null values for Blobs

Fixes: #7604

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), MySQL and PostgreSQL. SQLite support for DomainAudit is now added.

How did you test it?

• Integration tests: Ran TestSQLiteDomainAuditPersistence on github actions

Potential risks

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

Release notes
SQLite support is added for domain audit

Documentation Changes
N/A

---

Detailed Description
Added SQLite support for DomainAudit.

• Created domain_audit_log table in SQLite schema
• • Updated the sql_doamin_audit_store and the domain_audit_log tables for PostgreSQL and MySQL to accept null values for Blobs

Impact Analysis

• Backward Compatibility: SQLite support is integrated with existing domain audit logic
• Forward Compatibility: Does not change existing logic

Testing Plan

• Unit Tests:
• Persistence Tests: Ran TestSQLiteDomainAuditPersistence 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? MySQL schema is updated with a new table; it can be rolled back with MySQL database release version
• Is there a kill switch to mitigate the impact immediately?

---

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]

Code Review ✅ Approved 2 resolved / 2 findings

Adds SQLite support for domain audit with fixes for DATETIME precision consistency and migration safety. No issues found.

✅ 2 resolved

✅ Bug: DATETIME missing (6) precision — inconsistent with schema

📄 schema/sqlite/cadence/schema.sql:313 📄 schema/sqlite/cadence/schema.sql:314 📄 schema/sqlite/cadence/versioned/v0.2/domain_audit_log.sql:12 📄 schema/sqlite/cadence/versioned/v0.2/domain_audit_log.sql:13
The domain_audit_log table uses plain DATETIME for created_time and last_updated_time, but every other datetime column in the same SQLite schema uses DATETIME(6) (microsecond precision), and the MySQL equivalent also explicitly uses DATETIME(6).

Since created_time is part of the composite primary key (domain_id, operation_type, created_time, event_id), truncating sub-second precision could cause primary key collisions when two audit events for the same domain and operation type occur within the same second. This would result in silent overwrites or insert failures.

Both schema.sql and the versioned migration v0.2/domain_audit_log.sql need to be updated.

✅ Bug: Mutating already-merged v0.7 migration breaks existing deployments

📄 schema/mysql/v8/cadence/versioned/v0.7/domain_audit_log.sql 📄 schema/postgres/cadence/versioned/v0.7/domain_audit_log.sql 📄 common/persistence/sql/sql_domain_audit_store.go:159
The MySQL and Postgres v0.7/domain_audit_log.sql files were already merged to master via PR #7818 on 2026-03-13. This PR modifies those versioned migration files in-place (changing BLOB NOT NULL to BLOB) rather than adding a new migration version (e.g., v0.8).

Any deployment that has already applied the v0.7 migration will have state_before and state_after as NOT NULL columns. The schema migration tool tracks applied versions and will not re-run v0.7, so those deployments will never get the nullable change. Meanwhile, getDataBlobBytes now returns nil (mapped to SQL NULL by the driver), which will cause INSERT failures on those databases because the columns still have NOT NULL constraints.

The fix is to add a new versioned migration (v0.8 for MySQL, corresponding version for Postgres) containing an ALTER TABLE statement to drop the NOT NULL constraint, rather than modifying the existing v0.7 CREATE TABLE.

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}