v5.7.0

What's Changed

• Prepare for Ruby 4.0 regarding CGI loading by @chaadow in #510
• Deprecate per-light error_notifier option by @bolshakov in #515
• Deprecate Light#with and #with_* methods by @bolshakov in #516
• Fix: Auto-reload Lua scripts when evicted from Redis memory by @bolshakov in #522
• Serialize recovery probing with exclusive locking by @bolshakov in #517 and #524

Non-functional changes:

• Simplify Recovery Metrics Tracking by @bolshakov in #513
• Refactor: Implement configuration proxy for data stores by @bolshakov in #521
• Refactor: Replace DI container with direct wiring in LightFactory by @bolshakov in #525
• Fix flaky specs by @bolshakov in #526
• Make metrics steps more modular to support future refactoring by @bolshakov in #528
• Refactor: Move FailSafe classes to Infrastructure layer with factory pattern in Wiring by @bolshakov in #514
• Extract Storage Abstractions from DataStore by @bolshakov in #530

Full Changelog: v5.6.0...v5.7.0

v5.6.0

What's Changed

• Update README.md to add an argument to the lambda by @chaadow in #505
• Escape light names to handle special characters such as # by @chaadow in #504
• Add delete option on the UI interface by @chaadow in #506
• Fix admin encoding issues on ruby 3.2 by @bolshakov in #508
• Refactoring: Split Metadata into Metrics and StateSnapshot by @bolshakov in #500

Full Changelog: v5.5.0...v5.6.0

v5.5.0

What's Changed

• Improve documented features coverage with feature tests by @bolshakov in #488
• Introduce Dependency Injection Architecture for Stoplight Configuration by @bolshakov in #485
• Establish Clean Architecture boundaries with Namespace Separation by @bolshakov in #491
• Add nonce to script tags in stoplight admin by @Tony-Chen-Persona in #481
• Remove unnecessary require statement by @Tony-Chen-Persona in #498
• Extract request tracking logic into dedicated tracker classes by @bolshakov in #495
• Refactor data stores to handle failure serialization and use float timestamps by @bolshakov @Lokideos in #496

New Contributors

• @Tony-Chen-Persona made their first contribution in #481

Full Changelog: v5.4.0...v5.5.0

v5.4.0

Stoplight v5.4.0

Major Performance Improvement

Replaced array-based time-series storage with a hash-based sliding window implementation in the Memory data store, delivering significant performance improvement.

• Before: O(n) array traversal on every metrics query
• After: O(1) amortized hash lookups
• Benchmark: 94,276 iterations/sec vs. 312 iterations/sec (60s window, 5min runtime)

This change enables Stoplight to handle high-throughput scenarios with minimal overhead when using in-memory storage.

Automatic Redis Failover

Circuit breakers now automatically fail over to an in-memory data store when Redis becomes unavailable, maintaining full functionality during outages.

• Zero-latency failover once circuits open (no Redis timeout delays)
• Full failure tracking and state transitions continue
• Automatic recovery when Redis reconnects
• Protected services remain protected during infrastructure issues

Improved Exception Context

RedLight exceptions now expose cool_off_time and recovery_scheduled_after properties, for better integration with monitoring tools and job processors like Sidekiq.

What's Changed

• Implement automatic failover to in-memory data store when Redis is unavailable by @bolshakov in #448
• The Rails generator now includes error notifier configuration out of the box by @bolshakov in #452
• Validate traffic recovery compatibility when calling Light#with by @bolshakov in #454
• Timestamp metrics at recording time, not event time by @bolshakov in #471
• Fix traffic control setup docs by @Lokideos in #483
• Expose cool_off_time and recovery_scheduled_after on Light properties in exceptions by @Lokideos in #484
• Replace array-based metrics with hash-based sliding window for O(1) performance by @bolshakov in #479

⚠️ Upgrade Notes

• New validation may surface previously silent configuration errors in traffic recovery settings

Full Changelog: v5.3.8...v5.4.0

v5.3.8 - Notification System Improvements

Notification System Improvements

Fixed Issues

• Corrected notification direction: Fixed incorrect GREEN → YELLOW notifications that should have been RED → YELLOW across all data stores
• Resolved missing time-based transition notifications: Time-based RED→YELLOW transitions (when cool-off time expires) now properly trigger notifications.
• Fixed Memory data store race condition: Eliminated premature recovery_started_at assignment that prevented proper transition notifications

Stoplight state transitions now generate consistent, reliable notifications across all scenarios. The notification deduplication system now functions correctly without gaps in the transition chain.

What's Changed

• Add Docker Build to release env by @bolshakov in #434
• Fix notification about transition from yellow to red by @bolshakov in #382
• Fix State Transition Notifications by @bolshakov in #436
• Send notification about YELLOW color transitions by @bolshakov in #439

Full Changelog: v5.3.5...v5.3.8

v5.3.5

Stoplight v5.3.5 Release Notes

This release focuses on improved compatibility and clearer support expectations for our users.

Expanded Redis/Valkey Compatibility

• Added official Valkey support alongside Redis compatibility
• Expanded CI testing to cover Redis 6.2, 7.2, 7.4, 8.0 and Valkey 7.2, 8.1
• Committed to maintaining compatibility with both Redis and Valkey in future releases

Clarified Maintenance Policy

We've completely rewritten our maintenance policy to provide clear expectations about version support. The new policy explains:

• Stoplight versions: We only actively support the latest major version (bug fixes and features go to current major only)
• Ruby support: We support Ruby versions that receive security updates from Ruby core team (currently 3.2.x, 3.3.x, 3.4.x)
• Data store support: We support Redis and Valkey versions that receive upstream security updates
• Deprecation timeline: Clear notice about when support will be dropped (tied to upstream EOL dates)

This policy ensures that we can focus resources on current, secure versions while providing users with predictable upgrade paths. We continue our commitment to semantic versioning and backward compatibility within minor releases.

What's Changed

• StepSecurity Apply security best practices by @bolshakov #397
• Remove code climate badge @bolshakov #405
• feat: Add Valkey Support @Lokideos #410
• Fix get_metadata.lua script error on DragonflyDB @ClearlyClaire #415
• Prevent Stoplight failure when redis is unreachable @bolshakov #418
• Update maintenance policy and CI matrix @bolshakov #422
• Fix typos in readme @duffuniverse #424
• Handle concurrent recovery completion in consecutive successes strategy @bolshakov #427
• Explain DragonflyDB support status @Lokideos #417

Full Changelog: v5.3.1...v5.3.5

Kudos to our new contributors @ClearlyClaire and @duffuniverse! 🚀

v5.3.1

Fixes automatic docker build

Full Changelog: v5.3.0...v5.3.1

v5.3.0

What's Changed

• Secure workflows with harden runner by @bolshakov in #379
• Use trusted publishers to release gem by @bolshakov in #390

Full Changelog: v5.2.0...v5.3.0

v5.2.0

Stoplight v5.2.0 Release Notes

We're excited to announce Stoplight v5.2.0, a significant release that introduces pluggable traffic control strategies, performance improvements, and enhanced recovery mechanisms. This release makes Stoplight more flexible for high-traffic environments.

🚦 New Feature: Traffic Control Strategies

Stoplight now supports pluggable traffic control strategies, moving beyond the traditional consecutive failure counting to support modern, percentage-based circuit-breaking patterns.

Two Built-in Strategies

Consecutive Errors (Default - Fully Backward Compatible)

The familiar behavior you know and love, now explicitly configurable:

# Existing code continues to work unchanged
light = Stoplight("API", threshold: 5)

# Or be explicit about the strategy
light = Stoplight("API", traffic_control: :consecutive_errors, threshold: 5)

Error Rate (New)

Perfect for high-traffic services and SLA-based monitoring:

# Trip when error rate exceeds 50% within a 5-minute window
light = Stoplight("Payment API", 
  traffic_control: :error_rate,
  window_size: 300,      # 5-minute sliding window
  threshold: 0.5         # 50% error rate
)

# Fine-tune with minimum request thresholds

light = Stoplight("Payment API",
  traffic_control: { error_rate: { min_requests: 100 } },
  window_size: 600,
  threshold: 0.6
)

When to use each strategy:

• Consecutive Errors: Low-medium traffic, simple behavior, occasional spikes expected
• Error Rate: High traffic, percentage-based SLAs, variable traffic patterns

🔄 Better Recovery: Consecutive Successes Strategy

The new Consecutive Successes recovery strategy replaces the previous single-success approach, providing more stable recovery behavior.

Configurable Recovery Thresholds

# Require 3 consecutive successful probes before resuming traffic
light = Stoplight("Payment API", recovery_threshold: 3)

# Default behavior (maintains backward compatibility)
light = Stoplight("Payment API")  # recovery_threshold: 1

Benefits

• 🔒 Prevents Flapping: No more rapid red → yellow → red cycles during unstable recovery periods
• ⚡ Still Fast: Healthy services pass multiple probes quickly
• ⚙️ Tunable: Balance stability vs. speed per service
• 🔄 Backward Compatible: Existing code uses recovery_threshold: 1

⚡ Performance Improvements

2.26x Faster Light Creation

We've completely refactored the configuration system, eliminating the ConfigProvider layer and implementing a direct, prototype-based approach:

• Before: 398k light creations/second
• After: 900k light creations/second
• Improvement: 2.26x faster ⚡

🔧 Configuration Enhancements

Self-Validating Configuration

Stoplight now validates configuration compatibility automatically:

# This will raise a helpful error
Stoplight("API", 
  traffic_control: :error_rate,
  threshold: 0.5
  # Missing required window_size!
)

fails with:

Stoplight::TrafficControl::ErrorRate strategy is incompatible with the Stoplight configuration: `window_size` should be set (Stoplight::Error::ConfigurationError)

🔄 Migration Guide

Fully Backward Compatible

No changes required! All existing Stoplight code continues to work exactly as before. The new features are opt-in.

Recommended Upgrades for High-Traffic Services

If you're running high-traffic services, consider migrating to error rate control:

# Before
light = Stoplight("API", threshold: 10, window_size: 300)

# After - error rate approach
light = Stoplight("API", 
  traffic_control: :error_rate,
  window_size: 300,
  threshold: 0.05,  # 5% - set this 2-3x above your normal error rate
  recovery_threshold: 3
)

This will turn Stoplight red when the error rate reaches 5% and will recover after 3 consecutive successful recovery probes.

To choose your threshold: Monitor your service's typical error rate over a few days, then set the threshold 2-3x higher. For example, if your service normally sees 1-2% errors, set the threshold around 0.05 (5%).

---

Upgrade today to take advantage of more intelligent circuit breaking, better performance, and improved reliability!

What's Changed

• Add Public Interface for Traffic Control Strategies Support by @bolshakov in #349
• Simplify Configuration System and Improve Light Creation Performance by @bolshakov in #374
• Add Configurable Consecutive Successes Recovery Strategy by @bolshakov in #375

Full Changelog: v5.1.0...v5.2.0

v5.1.0

What's Changed

• Centralize Configuration Transformations by @bolshakov in #348
• Generators by @Lokideos in #343

Full Changelog: v5.0.2...v5.1.0