Skip to content

Cu 868jzwene - #11

Closed
harshaellanki wants to merge 9 commits into
mainfrom
cu_868jzwene
Closed

Cu 868jzwene#11
harshaellanki wants to merge 9 commits into
mainfrom
cu_868jzwene

Conversation

@harshaellanki

Copy link
Copy Markdown
Contributor

No description provided.

TreyE and others added 9 commits August 21, 2026 14:04
Restores/adds infrastructure required so that the following cherry-picks
apply cleanly:

  - protocols/registry.rb + protocols.rb
  - protocols/base/{,channel_proxy,connection_proxy}.rb
  - protocols/arn_protocol.rb + arn/* (wholesale)
  - protocols/http/faraday_version_adapter.rb
  - helpers.rb, paginator.rb, worker_pool.rb
  - rspec/event_routing_matchers.rb
  - uris/arn_uri.rb
  - configure/server_configurations{,/*}.rb
  - realigned connection_manager.rb, connection.rb, subscriber.rb,
    channel.rb, amqp_protocol.rb, http_protocol.rb, amqp/bunny_*,
    http/faraday_*, mime_decode.rb, ruby_versions.rb, event_source.rb
  - Gemfile / event_source.gemspec / .github/workflows/rspec.yml /
    .rubocop.yml adjusted for the new baseline

DC branding preserved:
  - spec.email = info@dchbx.com
  - spec.homepage = https://github.com/dchbx/event_source
  - LICENSE.txt untouched
  - lib/event_source/version.rb untouched
Subscriber routing specs now check the routed action more carefully.
* remove pii and payload from loggers

* spec fix

* updated few loggers based on PR comments
BunnyChannelProxy#create_channel creates one confirm-enabled publisher
channel per AsyncAPI channel item, and publish operations are resolved
from a shared registry, so every thread publishing a given event reuses
one Bunny::Channel. BunnyExchangeProxy#publish then did an unsynchronized
publish-then-wait on it.

Bunny's confirm state is channel-wide, and wait_for_confirms blocks until
the channel's entire unconfirmed set drains. With N threads parked in
poll, the drain pushes one token and signals one waiter; the other N-1
stay parked until continuation_timeout elapses and Timeout::Error is
raised. Under sustained load the set may never be observed empty at all.
The HTTP subscriber path makes this concrete: FaradayChannelProxy
hardcodes 5 worker threads, each able to publish to the same exchange.

Taking the lock on the channel rather than the proxy scopes it to the
contended state, which several exchanges may share via
create_exchange_to_exchange_bindings. Channel#synchronize wraps
@publishing_mutex, a reentrant Monitor by default, which basic_publish
re-enters through Session#send_frameset; neither the reader loop that
delivers acks nor the heartbeat sender acquires it, so holding it across
the wait cannot deadlock. Verified against bunny 2.19 through 3.1.

Serializing also fixes a correctness bug: wait_for_confirms ends with
read_and_reset_only_acks_received on channel-level state, so a nack for
one thread's message could be reported to another, or consumed by the
first and lost for the second.

Timeout::Error is now re-raised as MessagePublishConfirmationError noting
the message may have been delivered, since publish returns before the
wait and the message is already on the wire. Both confirmation errors
name the exchange and routing key.

The concurrency spec fails deterministically without this change: four
of five threads raise Timeout::Error at continuation_timeout.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Adding pooling for publisher confirmation.

* removed ruby 2.0.5 support

---------

Co-authored-by: HArsHA Ellanki <h_vardhan@yahoo.com>
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
run: |
bundle config path vendor/bundle
bundle install
bundle exec rubocop-git trunk
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants