UPDATE: Looks like this has been a long-standing issue with Byebug: https://github.com/deivid-rodriguez/byebug/issues/487
When I run my Rails app using Puma with multiple workers in cluster mode and the app is processing concurrent requests, byebug and pry cause strange behavior on the terminal. For example, I'll try to type in quit at a breakpoint, but it will non-deterministically come out as qit, ui, qt, etc. I have to type each individual character (e.g., q, u, i, t) several times until I can get the desired command.
However, even once I manage to type out the right command, it still complains that qit, ui, etc. doesn't exist after pressing enter even though the correct command is nominally on the screen. If I press enter a second time, it will appear to run the correct command even though there isn't any command waiting in the prompt anymore (because I already pressed enter the first time). Even so, I can only get it to execute a command once; after that, breakpoints don't work at all, and I have to restart my server.
I never have this problem when using Puma in single mode in development, but in my use case I have to use multiple workers in development. I'm running SSR in a separate Node process that issues a request during SSR back to the Rails server. In single mode, there's only one process, and the SSR request times out because Puma is still waiting on the browser request, but the browser request can't finish until SSR finishes. With multiple workers, one process handles the browser request while the other handles the SSR request.
Does anyone have an idea why this might be happening? Note, I've also experienced similar problems when using byebug and pry with Unicorn and Passenger while handling concurrent requests. Seems like a deeper problem than any one library.