Skip to main content
Version: 1.12

1.11.x Release Notes

This page summarizes notable changes in the 1.11 minor series. Patch-level releases are listed below.

1.11 focuses on higher throughput, production-friendly logging, and improved Redis connectivity under load. The foundation has been optimized substantially.

1.11.11​

New

  • Redis: Added server.redis.protocol configuration option.
  • Why: This allows forcing the Redis protocol version (2 or 3). It was introduced to improve stability during high-load "Pipeline BruteForce" operations. In these scenarios, RESP3 asynchronous push messages (like invalidations) could arrive within a pipeline, potentially causing parsing failures. Forcing the protocol to 2 provides a stable fallback.

1.11.10​

Lua

  • OpenTelemetry: Added finish() alias for span:end(). In Lua, end is a reserved keyword, which makes calling :end() directly a syntax error.
  • OpenTelemetry: Documented tr:with_span(name, function, options) which was available since 1.11.5 but missing from the API documentation.

Documentation

  • Lua API: Updated nauthilus_opentelemetry documentation with with_span and the :end() keyword warning.

1.11.5​

New

  • Tracing: OpenTelemetry tracing via server.insights.tracing with OTLP/HTTP exporter, configurable sampling, propagators, and Redis client instrumentation.
  • Redis compatibility: New options under server.redis to fine-tune RESP3 features and compatibility:
    • identity_enabled to toggle CLIENT SETINFO.
    • maint_notifications_enabled to toggle CLIENT MAINT_NOTIFICATIONS (RESP3 push).
    • client_tracking block to enable RESP3 client-side caching with bcast, noloop, opt_in/opt_out, and prefixes.
  • Lua: New module nauthilus_opentelemetry allowing scripts to create spans, set attributes/events/status, use baggage, and inject/extract headers.

Documentation

  • New guide: Tracing (OpenTelemetry) with configuration and examples.
  • Server Configuration updated with server.insights.tracing and Redis compatibility options.
  • Lua API extended with nauthilus_opentelemetry usage.

See also

  • Guides → Tracing (OpenTelemetry): /docs/guides/tracing-opentelemetry
  • Configuration → Server Configuration: /docs/configuration/server-configuration
  • Lua API → OpenTelemetry: /docs/lua-api/opentelemetry

Upgrade notes

  • Tracing is opt-in; defaults remain disabled. When enabling Redis tracing, consider sampling to control volume.
  • RESP3 is preferred by the client to support push notifications. If you use legacy proxies that don’t support RESP3 features, keep the new Redis options disabled.

1.11.4​

New

  • Async REST endpoints for long-running cleanup jobs:
    • DELETE /api/v1/cache/flush/async enqueues a user cache flush and returns 202 Accepted with a jobId.
    • DELETE /api/v1/bruteforce/flush/async enqueues a brute-force cleanup for an IP and returns 202 Accepted with a jobId.
    • GET /api/v1/async/jobs/{jobId} returns the job status (QUEUED|INPROGRESS|DONE|ERROR) and resultCount.
  • Debugging: New DbgModule account for account lookup/mapping related operations.
  • Redis: Client Tracking configuration (server.redis.client_tracking) to enable RESP3 CLIENT TRACKING with flags like bcast, noloop, opt_in/opt_out, and prefixes.
  • Lua Redis API: redis_set now supports full option set (NX, XX, GET, KEEPTTL, EX, PX, EXAT, PXAT) via an options table while keeping backward compatibility with a numeric TTL.
  • Lua Redis API: New redis_hmget(handle, key, field1, field2, ...) returning a table field -> value (missing fields are nil).
  • Redis Pipeline: hmget supported in redis_pipeline.

Documentation

  • REST API updated with the new async endpoints and the async job status endpoint.
  • Server Configuration updated for server.redis.client_tracking including examples.
  • Lua Redis API updated for redis_set options and new redis_hmget.
  • Full Configuration Example updated to include a client_tracking block.

Deprecated/Removed

  • In‑process request de‑duplication has been removed due to persistent instability. The following configuration keys are deprecated and ignored starting with v1.11.4:
    • server.dedup.in_process_enabled
    • server.timeouts.singleflight_work Existing configurations containing these keys do not fail, but the settings have no effect.

See also

  • REST API → Cleanup and Async Jobs: /docs/rest-api
  • Configuration → Server Configuration: /docs/configuration/server-configuration
  • Lua API → Redis: /docs/lua-api/redis
  • Full Configuration Example: /docs/configuration/full-example

1.11.3​

New

  • Redis: In‑process account name cache (server.redis.account_local_cache) to reduce repeated lookups for frequently used users. Disabled by default.
  • Redis: Client‑side command batching (server.redis.batching) to pipeline small commands and reduce round‑trips under load. Disabled by default.
  • HTTP middlewares: Feature switches to enable/disable individual middlewares (server.middlewares), including logging, limit, recovery, trusted_proxies, request_decompression, response_compression, and metrics. Enabled by default unless explicitly set to false.

Documentation

  • Server Configuration updated with defaults and YAML examples for the new Redis features.
  • Full Configuration Example updated accordingly.

See also

  • Configuration → Server Configuration → HTTP Middlewares: /docs/configuration/server-configuration#servermiddlewares
  • Configuration → Server Configuration → Account Local Cache: /docs/configuration/server-configuration#serverredisaccount_local_cache
  • Configuration → Server Configuration → Batching: /docs/configuration/server-configuration#serverredisbatching
  • Full Configuration Example: /docs/configuration/full-example

Performance and internal changes

  • Redis cleanup paths switched from DEL to UNLINK where safe to avoid blocking on large keys.
  • Extensive use of pipelining for multi-key deletes to reduce Redis round-trips; improvements are effective in both standalone and cluster deployments.

Upgrade notes

  • The async endpoints are additive and do not change the behavior of existing synchronous endpoints.
  • Consumers performing large cleanup operations should prefer the /async variants and poll the job status endpoint to avoid client timeouts.

Highlights​

  • New log level: notice
    • Emits essential, high-signal events suited for production.
  • Redis connection and timeout tuning
    • Better pooling defaults and improved behavior under network hiccups; clear guidance for pool sizing.
  • Core runtime optimizations
    • Significantly reduced overhead in hot paths for higher request throughput.

Configuration changes (New in v1.11.0)​

Logging​

  • server.log.level supports a new level: notice
    • Intended for production to keep logs concise while preserving operational visibility.

Example:

server:
  log:
    level: notice

Redis​

  • Connection handling tuned for busy deployments.
  • Time budget enforcement aligns with server.timeouts.redis_read and server.timeouts.redis_write.
  • Guidance for pool tuning added to Server Configuration.

See:

  • Configuration → Server Configuration → Redis → Connection and timeout tuning
  • Configuration → Server Configuration → Timeouts

Performance​

  • Internal subsystems refactored to reduce allocations and contention in authentication flows.
  • Improved connection reuse and reduced churn for Redis workloads.

Compatibility​

  • No breaking configuration changes compared to 1.10.
  • The new notice level is additive and fully backward compatible.

Lua runtime loading​

  • The legacy dynamic_loader has been removed. Calls to dynamic_loader are now no-ops and emit a warning to the log if invoked. Use plain require("<module>") in Lua scripts.

Upgrade notes​

  • Review your logging configuration and consider using notice in production.
  • Revisit Redis pool_size and idle_pool_size if you previously tuned around connection churn.
  • Validate timeouts for redis_read and redis_write against your network conditions.