anyone have slow debugger interface when using tailwindcss puma plugin?

[laptopmutia]

idk where to open the issue tailwind or puma or debug

the problem that I have is the debug (rdbg) is really slow when I use/activate tailwindcss plugin
its like ultra lagging like when I press @ it will come to the screen a few seconds later

my puma.rb

# Puma can serve each request in a thread from an internal thread pool.
# The `threads` method setting takes two numbers: a minimum and maximum.
# Any libraries that use thread pools should be configured to match
# the maximum value specified for Puma. Default is set to 5 threads for minimum
# and maximum; this matches the default thread size of Active Record.
#
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

# Specifies the `worker_timeout` threshold that Puma will use to wait before
# terminating a worker in development environments.
#
worker_timeout 3600 if ENV.fetch("RAILS_ENV", "development") == "development"

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
#
port ENV.fetch("PORT") { 3000 }

# Specifies the `environment` that Puma will run in.
#
environment ENV.fetch("RAILS_ENV") { "development" }

# Specifies the `pidfile` that Puma will use.
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

# Specifies the number of `workers` to boot in clustered mode.
# Workers are forked web server processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
#
# workers ENV.fetch("WEB_CONCURRENCY") { 2 }

# Use the `preload_app!` method when specifying a `workers` number.
# This directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
#
# preload_app!

# Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart

# run tailwind server
plugin :tailwindcss if ENV.fetch("RAILS_ENV", "development") == "development"

I'm on macbook pro m3 ruby 3.3.0 and rails "~> 7.1.3", ">= 7.1.3.2", puma 6.4.2, tailwindcss-rails 2.4.0, debug 1.9.2

[flavorjones]

@joyoy96 Thanks for asking this question. I think I've reproduced what you're seeing ... I would describe it as "missing keystrokes", though -- some keystrokes just get lost. Does that sound like we're seeing the same thing?

@npezza93 since you wrote the puma plugin, have you noticed any problems like this when debugging?

[flavorjones]

@st0012 I'm wondering if you've seen something like this before, with lost keystrokes to the debugger. Is it possible that the forked process in https://github.com/rails/tailwindcss-rails/blob/main/lib/puma/plugin/tailwindcss.rb is stealing some of the keyboard tty input?

[laptopmutia]

@flavorjones you are really correct I confirm we have the same issue, its just my english that is difference with you

[st0012]

I wasn't aware that the environment and app I used for testing had other things turning off tty, which completely messed up my previous result.

Debug

With Reline 0.5.2 (latest release)

Missing keystrokes as described.

With Reline 0.4.3

Missing keystrokes as described.

With RUBY_DEBUG_NO_RELINE=1

Everything works as expected.

IRB

With Reline 0.5.2 (latest release)

Missing keystrokes as described and sometimes freezes after a few inputs.

With Reline 0.4.3

Missing keystrokes as described and sometimes freezes after a few inputs.

Pry

Missing keystrokes as described and sometimes freezes after a few inputs.

Conclusion (for now)

• Using debug with RUBY_DEBUG_NO_RELINE=1 set somewhere should provide you some acceptable debugging experience with the plugin.
• @tompng Since debug can work WITHOUT Reline, I think it's at least somewhat related to it. But consider we can see the same behaviour with Reline 0.4.3 too, it's probably not caused by recent changes.

[st0012]

Actually, I can reproduce the problem even without the tailwindcss plugin. So this may be a problem between Reline and Puma (or multi-threaded context in general).

Sorry this part is wrong as it's caused by another issue in my environment.

[flavorjones]

@st0012 Thanks, at least on my local system, setting the environment variable RUBY_DEBUG_NO_RELINE=1 works for me.

[flavorjones]

@st0012 @tompng Should I open an issue with reline?

[tompng]

I don't think this is an issue of Reline.
Missing keystrokes can be caused by using stdin raw mode with multiprocess.
Reline and also Readline does not work in forked parent and child processes at the same time. I think this is same for any other rich line editor library that uses raw mode.

# Reproduction of missin keystroke with Readline
require 'readline'
p Readline => Readline::VERSION
fork do
  loop{p forked: Readline.readline('forked>')}
end
loop{p main: Readline.readline('main>')}

[flavorjones]

I've updated the README with some information that should be helpful:

https://github.com/rails/tailwindcss-rails?tab=readme-ov-file#lost-keystrokes-or-hanging-when-using-rubydebug-with-the-puma-plugin

[flavorjones]

I've shipped https://github.com/rails/tailwindcss-rails/releases/tag/v2.4.1 which includes @tompng's fix.

[st0012]

Thanks for the swift release 🙌
Maybe the suggested solution in readme could now be to use v2.4.1+ instead, as RUBY_DEBUG_NO_RELINE degrades users' experience with the debugger.

Update: I've opened #350 for it.