# audit log 0.7.1 release notes

Version 0.7.1 adds opt-in SQL Server manual audit logging and audit table installation while
preserving PostgreSQL as the default provider. The [Quick Start](../../README.md#quick-start)
documents installation of `@nestarc/audit-log@0.7.1` for PostgreSQL; use the
[SQL Server guide](../sql-server.md) for an existing SQL Server application.
See the [CHANGELOG](../../CHANGELOG.md) for version changes.

## Node.js security requirement

Version 0.7.1 requires Node 22.23.4+ in the 22.x line or 24.22.1+ in the 24.x line, incorporating
the upstream fix for CVE-2026-111497. See the
[Node.js security release](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases).
The workflows pin those patched runtimes and run a version/Brotli regression gate. Gate results
belong to the tested commit's CI record; the earlier validation and performance results below
retain their original runtime versions.

An npm update or `engines` declaration does not replace the host's Node binary. Update deployment
runtimes, rebuild images or deployment artifacts, and restart the application processes.

## SQL Server manual logging

Configure `provider: 'sqlserver'` and pass the application's generated `Prisma` namespace to use
`AuditService.log(input, tx?)`. Passing the business transaction's client writes the audit row on
that transaction, so successful business and audit writes commit together. An error propagated
out of the transaction callback rolls both back. Manual events retain actor and tenant policy,
context metadata, reason, and redaction behavior.

The SQL Server schema utilities install a flat audit table with Unicode `NVARCHAR(MAX)` text,
JSON checks, UTC timestamps, a clustered `(created_at, id)` index, and UPDATE/DELETE rejection
triggers. The installer executes trigger definitions in separate batches, validates existing
layouts, and restores trigger enforcement when reapplied. Omitting the provider continues to
select PostgreSQL. Existing PostgreSQL automatic tracking and storage APIs retain their behavior.

Use the [SQL Server guide](../sql-server.md) for module registration, transaction examples,
installation privileges, and executable DDL formats.

## Supported environment and current limits

The recorded SQL Server validation used Linux x64 Ubuntu 24.04, Node 24.11.1, SQL Server 2025 CU10, and
Prisma CLI, client, and MSSQL adapter pinned to 7.10.0. The preflight records the actual server
version and container image digest. This validation does not establish support for every SQL
Server build or Prisma version in the package's PostgreSQL peer matrix. Node 24.11.1 is historical
evidence, not a supported runtime for new deployments under the security requirement above.

- SQL Server automatic tracking, `createAuditedClient`, `createAuditExtension`, and factory
  `extension` configuration are unsupported and rejected.
- SQL Server query, lookup, scan, CSV export, retention, partitions, GIN indexes, and rule
  enforcement are unsupported. The PostgreSQL stream store remains PostgreSQL-specific.
- Manual atomicity requires the caller to pass the same business transaction and propagate
  audit failures. Omitting `tx` uses the base client; catching a JavaScript policy error does
  not itself force transaction rollback.
- Schema installation supports compatible flat tables. It does not migrate arbitrary existing
  layouts or convert PostgreSQL tables, and its DDL batches are not wrapped in one transaction.
- Mutation triggers reject UPDATE and DELETE affecting existing rows. They do not protect
  against privileged trigger changes or `TRUNCATE TABLE`. The separate-identity smoke covers
  one scoped installer and an insert-only runtime; production identities and grants still
  need deployment-specific validation.
- SQL Server text columns do not receive tenant, actor, action, or target indexes. Applications
  must design any additional searchable columns and indexes for their workload.

The exact published PostgreSQL ecosystem baseline remains tenancy 0.15.0, audit-log 0.5.0, and
soft-delete 0.7.3. The packed-package ecosystem gate substitutes the audit-log 0.7.1 artifact and
published soft-delete 0.7.4 with strict peer dependencies; the checked-in baseline is unchanged.

## Verification results

PR #4 was merged into `main` at
[`a2d2706`](https://github.com/nestarc/nestjs-audit-log/commit/a2d2706041de435190683e3ea73593b7262c091e).
The post-merge [CI run](https://github.com/nestarc/nestjs-audit-log/actions/runs/40182576141) and
[MSSQL preflight run](https://github.com/nestarc/nestjs-audit-log/actions/runs/40182576155) succeeded.
Version 0.7.1 at
[`321a8da`](https://github.com/nestarc/nestjs-audit-log/commit/321a8da0c43a959d596897a4027a46c75054e357)
also passed all 12 [standard CI jobs](https://github.com/nestarc/nestjs-audit-log/actions/runs/40183158545)
and [MSSQL preflight](https://github.com/nestarc/nestjs-audit-log/actions/runs/40183158542).
This includes 567 unit tests, 117 PostgreSQL E2E tests, the nine NestJS/Prisma compatibility
combinations, strict registry/tarball ecosystem consumers, and packed documentation consumers.
The publishing workflow now requires both PostgreSQL ecosystem and MSSQL validation gates.

MSSQL preflight passed 10 driver probes and 15 packed-library probes. They cover concurrent
commit and rollback isolation, business and audit SQL failures, actor and tenant policies,
redaction, Unicode and long-string binding, trigger installation and reapplication, multi-row
mutation rejection, unsupported API rejection, and connection recovery after failures and
transaction timeouts. The long-string driver checks include 3,999, 4,000, 4,001, 8,001, and 65,536
UTF-16 code units. Both runners create disposable databases and report cleanup outcomes.

The preflight also includes ten [separate-identity smoke probes](../sql-server.md#separate-installation-and-runtime-identities)
for a scoped installer and a runtime with audit `INSERT` only. They verify real login/user identity,
effective permissions, installation and reapplication, commit/rollback atomicity, audit-error
recovery, forbidden reads/mutations/DDL, and recovery after permission failures. Bootstrap queries
independently check stored rows and DDL state; child and runner reports record user, login and
database cleanup. The same workflow is required by the publishing gate. Final release-commit
results are recorded in the release PR and its CI artifacts.

## Performance verification

The [performance workflow](https://github.com/nestarc/nestjs-audit-log/actions/runs/40183158537)
passed, and the [benchmark documentation](../benchmarks.md#recorded-candidate-results--2026-10-25)
preserves the environment, artifact identities, every measured latency and all three PostgreSQL
executions. Each block used 50 warmups, 500 measurements and four repeats; concurrency was 1 or 4.

- PostgreSQL: 108,000 measured operations across three executions against published 0.7.0.
  No consistent broad regression reproduced across the executions, but hosted-runner variation
  was substantial. One run showed +24.45% in the small/concurrency-1 paired mean ratio, and the
  third showed +8.58% for large/concurrency-1. These results do not establish performance
  equivalence or exclude workload-specific regressions; retain the full comparison table.
  Large/concurrency-1 P99 and automatic create/delete P95 ratios increased in all three
  executions, so tail-latency behavior remains an unresolved observation for latency-sensitive use.
- SQL Server: 16,000 measured operations, 17,600 transactions including warmups and 8,800 audit
  rows. The median of four paired mean increments was +0.731 ms / +1.041 ms for small JSON at
  concurrency 1 / 4, and +44.939 ms / +44.296 ms for JSON occupying 128 KiB in NVARCHAR. Large
  payload cost was visible in all repeats. These are whole-transaction observations, not a
  production latency guarantee or a driver-only cost measurement.
- Correctness and cleanup passed for every measured block. The SQL Server data/log files did
  not grow during measurement. Different payload definitions and drivers prevent cross-database
  rankings. An application's latency budget still requires deployment-specific measurement.

## Publication procedure

The [maintainer procedure](../maintaining.md#071-verification-and-publication) covers finalizing
the packaged documentation before tagging, validating the release commit, explicit publication,
and verification of the resulting registry artifact. CI and tarball verification establish the
tested code and package contents; the release or PR records the publication outcome.