[swombat]

Proposal — feedback welcome

Related to #97. This draft proposes an opt-in synchronous write mode rather than changing the default batching behavior or introducing automatic retries.

The problem is a changed acknowledgement boundary: the batched writer returns to broadcast's caller before inserting, so an insert failure can only be reported later; the failed batch is discarded. Some applications may prefer the pre-batching trade-off of paying write latency in the broadcasting thread and receiving insertion errors directly.

Scope

• Keep asynchronous batching as the default.
• Allow explicit synchronous writes through writer_async: false in Cable configuration.
• Preserve proportional asynchronous trimming, without conflating trimming failure with insertion failure.
• Reject new writes after shutdown and wait for in-flight writes.
• Document the limits: no subscriber-delivery guarantee, no automatic retry or exactly-once claim, and no guarantee against rollback by an enclosing application transaction.

This is an alternative policy applications can choose, not a claim to repair every failed asynchronous batch. In particular it does not solve ambiguous database commit outcomes.

Review request

Would maintainers prefer this explicit opt-out, documentation-only clarification of the current contract, or a separately specified retry policy? Marked draft to keep that design choice visible.

Tests and provenance

New coverage checks configuration defaults/selection, caller-thread insertion, error propagation without retry, encrypted storage, asynchronous proportional trimming, trimming error isolation, and shutdown behavior.

Final local suite: 51 tests, 140 assertions, zero failures/errors/skips. Changed-file RuboCop: six applicable files, no offenses. git diff --check passes. The separate observation test published in #97 was run successfully and is not included in this patch.

Implementation and tests prepared with an OpenAI GPT-6.1 Sol helper, then reviewed and tested by Mira. No deployment or downstream dependency update is included.

Local verification uses Ruby 4.0.6, Rails 8.1.4 and SQLite. The PostgreSQL/MySQL and wider Rails/Ruby matrix remain for upstream CI; no claim that they passed locally.

[swombat]

The one red matrix job appears to be a runner service-startup failure, before checkout or tests, rather than a test failure:

Tests (postgres, rails_main, 3.3) failed in Initialize containers, starting the workflow's MySQL service:

failed to bind host port for 0.0.0.0:33060:172.18.0.2:3306/tcp: address already in use
Docker start fail with exit code 1

Checkout, dependency installation, database setup and tests were all skipped. The other 35 test matrix jobs and lint passed at f42fc20bc89bd4fbd2e4e79c9ed269c96b7fe02a.

Could a maintainer please rerun the failed job? I tried the job rerun endpoint, but GitHub returned HTTP 403 (repository admin rights required). I have not changed code or pushed an empty commit to trigger another full matrix.

[npezza93]

A fix for this is on main