| 26 Jan 2022 |
 nateberkopec | I don't think we've ever seen that in puma itself though | 14:23:14 |
| nateberkopec | I'm trying to look through changes for things that might have changed here | 14:23:34 |
| nateberkopec | There's changes to request.rb, which would be the place for something like this to happen, but they look like formatting changes mostly | 14:24:04 |
| nateberkopec | I'm struggling to see what it could be other than changes to request.rb? | 14:38:07 |
 @baelter:matrix.org | Seems pin pointed to my PR around low level error handling.https://github.com/puma/puma/commit/f8acac1f0702fea1a4f88d68a40bb2f53650b14c Can't spot anything obvious though :( | 15:53:34 |
| @baelter:matrix.org | Some buffer not cleared/rewinded as it should maybe? | 16:23:06 |
| nateberkopec | Will merge the revert soon | 22:21:43 |
| nateberkopec | We can figure out what the exact cause was later | 22:21:53 |
| nateberkopec | I think one big question in my mind is was this wiping headers/displaying blanks where it should have returned a value, or is this a security issue where headers were polluting across other requests. | 22:22:45 |
| nateberkopec | One user seemed to be reporting the latter | 22:22:55 |
| nateberkopec | but the other two seemed to report blanks | 22:23:01 |
| nateberkopec | One addition made in #2731 was lines.clear so I'm hoping it's the former. | 22:23:47 |
 dentarg | Can always publish security info when we know
For now, merge revert and release new version
And yank 5.6.0? | 22:24:51 |
| dentarg | FYI I'm about to go to bed now | 22:25:06 |
| nateberkopec | @dentarg np thanks for your help yoday | 22:25:18 |
| nateberkopec | dentarg: ^^ | 22:25:20 |
| nateberkopec | * @dentarg np thanks for your help today | 22:26:13 |
| nateberkopec | 5.6.1 going out with the revert now | 23:46:30 |
| nateberkopec | Will appreciate anyone's eyes on that PR in the coming days to figure out what we missed and what went wrong | 23:47:28 |
| 27 Jan 2022 |
| @baelter:matrix.org | In reply to @nateberkopec:matrix.org
One addition made in #2731 was lines.clear so I'm hoping it's the former. My eyes also got caught on that line. Will try to reproduce with specs... | 07:30:37 |
| @baelter:matrix.org | @pedantic-git's specs still fail on occasion when that line is removed | 08:33:25 |
| @baelter:matrix.org | lines buffer is always empty when running those specs, so not that | 08:45:45 |
| @baelter:matrix.org | Status is always 304 on the failing specs | 10:13:45 |
| @baelter:matrix.org | If I log env["rack.session"] in write_response the error goes away | 10:19:42 |
| @baelter:matrix.org | Syncing handle_request or write_response does not help | 10:42:00 |
| @baelter:matrix.org | Adding logging to the loop in process_client client.reset in the with_force_shutdown is always called when a spec fails, and not when it passes. | 11:20:19 |
| @baelter:matrix.org changed their display name from Anders Bälter to baelter. | 11:20:46 |
| dentarg | Created the GitHub release for 5.6.1 | 18:32:31 |
| @baelter:matrix.org | Found a 3 lines that where added in the write_response refactoring. Removing those and all name.pn specs work. Making a new PR. | 21:14:16 |
| nateberkopec | baelter: thanks for hopping in to debug this | 21:15:04 |
