@schneems

1. Do we need a job testing with rack v1 { os: ubuntu-22.04 , ruby: 3.0 , rack-v: ' rack1' }?

2. Sorry, I had a comment that stated '# below is only needed for Ruby 2.4', I only meant the following line.

But, now that we're at v3.0, should we try to leave each installed version of RubyGems and Bundler as is? In some cases they're updated. To fix, both MRI & nonMRI would need rubygems: and bundler: either removed or set to default.

Do we need a job testing with rack v1 { os: ubuntu-22.04 , ruby: 3.0 , rack-v: ' rack1' }?

I added a proposed policy doc today #3700. If we follow the policy for Rack support listed there, then rack1 support can be removed. I'll add another commit to remove that test, I wasn't sure if it would be runnable with Ruby 3.0 or not and wanted CI to tell me.

Sorry, I had a comment that stated '# below is only needed for Ruby 2.4', I only meant the following line.

I figured that one out after a cascade of CI failures 😅. In blame, the other lines were added after you added that comment (IIRC).

But, now that we're at v3.0, should we try to leave each installed version of RubyGems and Bundler as is? In some cases they're updated. To fix, both MRI & nonMRI would need rubygems: and bundler: either removed or set to default.

I added them back in as they were originally. I'm not totally following what your asking or suggesting here. For github actions yaml I tend to make fairly mechanical changes, if you can make inline code suggestions or describe a higher level change, I'll be happy to look into it.

I see your commit on this branch, thanks. Stepping out for a bit if you need to iterate.

Yes, added the commit. I'm too familiar with setup-ruby and setup-ruby-pkgs, so I added the links in the yml file.

Re the failures, I've got PR #3694 (only test fixes) and also PR #3582 (sizable refactor), both of which seem to pass CI. Not sure why #3582 is passing the few odd jobs that fail, I need to compare the two.

PR #3582 doesn't change any public API's, but it may mess up a lot of open PR's when it's merged. Simply put, it encapsulates all request code in Client. Or, when Client is finished, it's the request is ready to be passed to the app.

This is all green now. Thanks for your help! I approved #3694, can you merge these two and resolve conflicts? (merge order is up to you).

I peeked at #3582 it seems large I've not dug in. If it's not a change we could merge post v7, there are some config related PRs that are ready to merge, but need rebase and re-test https://github.com/puma/puma/issues?q=state%3Aopen%20label%3Av7. If those are merged and tests are passsing on this #3582 I'm okay merging it in (pending a review).

This is all green now

I did run the failed tests again, but it shows the intermittent issues with CI (fail, then pass).

can you merge these two and resolve conflicts?

Not sure what you mean by two? This and #3694?

I'd like to look at why tests are passing with #3582, because I did not make the changes that were contained in #3694.

This and #3694?

Yes.

I'd like to look at why tests are passing with #3582, because I did not make the changes that were contained in #3694.

It's my general assumption that the suite is flappy right now and that some re-starts fix intermittent issues. As long as they're all green once, that's good enough for me, for now.

This is looking great!!

Some other things I found that can probably be updated or removed:

• puma/README.md

  Lines 435 to 446 in ee9b2c4

  	## Known Bugs
  	For MRI versions 2.2.7, 2.2.8, 2.2.9, 2.2.10, 2.3.4 and 2.4.1, you may see ```stream closed in another thread (IOError)```. It may be caused by a [Ruby bug](https://bugs.ruby-lang.org/issues/13632). It can be fixed with the gem https://rubygems.org/gems/stopgap_13632:
  	```ruby
  	if %w(2.2.7 2.2.8 2.2.9 2.2.10 2.3.4 2.4.1).include? RUBY_VERSION
  	begin
  	require 'stopgap_13632'
  	rescue LoadError
  	end
  	end
  	```

  (Might want to keep this around for people using older versions? But imo the readme should reflect master)

• puma/ext/puma_http11/extconf.rb

  Lines 56 to 63 in ee9b2c4

  	# Random.bytes available in Ruby 2.5 and later, Random::DEFAULT deprecated in 3.0
  	if Random.respond_to?(:bytes)
  	$defs.push "-DHAVE_RANDOM_BYTES"
  	puts "checking for Random.bytes... yes"
  	else
  	puts "checking for Random.bytes... no"
  	end
  	end

• puma/ext/puma_http11/extconf.rb

  Lines 69 to 77 in ee9b2c4

  	if respond_to?(:append_cflags, true) # Ruby 2.5 and later
  	append_cflags(config_string('WERRORFLAG') || '-Werror')
  	append_cflags '-Wno-implicit-fallthrough'
  	else
  	# flag may not exist on some platforms, -Werror may not be defined on some platforms, but
  	# works with all in current CI
  	$CFLAGS << " #{config_string('WERRORFLAG') || '-Werror'}"
  	$CFLAGS << ' -Wno-implicit-fallthrough'
  	end

• puma/lib/puma/cluster/worker_handle.rb

  Lines 60 to 72 in ee9b2c4

  	# @todo remove each once Ruby 2.5 is no longer supported
  	status.tr('}{"', '').strip.split(", ").each do |kv|
  	cntr = 0
  	kv.split(':').each do |t|
  	if cntr == 0
  	k = t
  	cntr = 1
  	else
  	v = t
  	end
  	end
  	hsh[k.to_sym] = v.to_i
  	end

• puma/lib/puma/cluster.rb

  Lines 376 to 380 in ee9b2c4

  	# Process::Waiter check here because there's a bug in Ruby 2.6 and below
  	# where calling thread_variable_get on a Process::Waiter will segfault.
  	# We can drop that clause once those versions of Ruby are no longer
  	# supported.
  	fork_safe = ->(t) { !t.is_a?(Process::Waiter) && t.thread_variable_get(:fork_safe) }

• puma/lib/puma/io_buffer.rb

  Lines 37 to 44 in ee9b2c4

  	# before Ruby 2.5, `write` would only take one argument
  	if RUBY_ENGINE != 'truffleruby'
  	alias_method :append, :write
  	else
  	def append(*strs)
  	strs.each { |str| write str }
  	end
  	end

• puma/lib/puma/launcher/bundle_pruner.rb

  Lines 40 to 41 in ee9b2c4

  	# Ruby 2.0+ defaults to true which breaks socket activation
  	args += [{:close_others => false}]

• puma/lib/puma/client.rb

  Lines 3 to 9 in ee9b2c4

  	class IO
  	# We need to use this for a jruby work around on both 1.8 and 1.9.
  	# So this either creates the constant (on 1.8), or harmlessly
  	# reopens it (on 1.9).
  	module WaitReadable
  	end
  	end

@joshuay03 thanks for the assist 💯 I searched for 2. and found some more references. Waiting on CI now.