You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A backend is a factory that produces the focused stores (state, metrics, recovery lock, recovery metrics) for one data store, which Stoplight assembles into the object a light uses; the windowed-vs-unbounded metrics choice is made during that assembly from the light's window setting. The Redis backend additionally wraps each store in a fail-safe decorator that falls back to an in-memory store and trips an internal breaker when the database is unreachable, so a storage outage degrades gracefully instead of raising. This ticket builds the equivalent ActiveRecord backend and wires it into the selection points normalized in #813.
The Redis backend is the reference to mirror one to one. The epic describes the connection model, the per-instance connection binding, and the fail-safe behavior.
Goal
Assemble the five stores into a working backend and wire it in, so configuring DataStore::ActiveRecord runs lights end to end with fail-safe degradation matching Redis.
What to do
Implement Wiring::ActiveRecord::Backend building the five stores, each wrapped in the existing fail-safe decorator with a memory fallback and a failover breaker, and bound to the config's connection class per instance.
Ensure windowed and unbounded configurations both wire the correct metrics store.
Acceptance criteria
A DataStore::ActiveRecord-configured light (built with a connection class) passes the color property/integration spec on SQLite and Postgres.
A spec shows two data stores built with different connection classes each write to their own connection, with no collision.
A spec shows that with the database connection killed mid-run, the light degrades through fail-safe: it does not raise, the error notifier fires, and the breaker serves from memory — matching the Redis fail-safe spec — and a saturated pool travels the same path.
A spec shows that, with a dedicated (isolated) connection class, a failure recorded inside a rolled-back app-level transaction is still counted.
A spec shows both windowed and unbounded configurations wire correctly and record through the right metrics store.
bundle exec steep check and bundle exec standardrb pass.
Background
A backend is a factory that produces the focused stores (state, metrics, recovery lock, recovery metrics) for one data store, which Stoplight assembles into the object a light uses; the windowed-vs-unbounded metrics choice is made during that assembly from the light's window setting. The Redis backend additionally wraps each store in a fail-safe decorator that falls back to an in-memory store and trips an internal breaker when the database is unreachable, so a storage outage degrades gracefully instead of raising. This ticket builds the equivalent ActiveRecord backend and wires it into the selection points normalized in #813.
The Redis backend is the reference to mirror one to one. The epic describes the connection model, the per-instance connection binding, and the fail-safe behavior.
Goal
Assemble the five stores into a working backend and wire it in, so configuring
DataStore::ActiveRecordruns lights end to end with fail-safe degradation matching Redis.What to do
Wiring::ActiveRecord::Backendbuilding the five stores, each wrapped in the existing fail-safe decorator with a memory fallback and a failover breaker, and bound to the config's connection class per instance.Acceptance criteria
DataStore::ActiveRecord-configured light (built with a connection class) passes the color property/integration spec on SQLite and Postgres.bundle exec steep checkandbundle exec standardrbpass.References
wiring/data_store_backend.rbwiring/redis/backend.rb,wiring/memory/backend.rbwiring/storage_set_builder.rbwiring/light_factory.rb,wiring/global_state.rbinfrastructure/fail_safe/