fix response clone bug #1565
fix response clone bug #1565
Conversation
…v server serve and intercept related resource plugin processing" This reverts commit 23fefca.
|
Took a little while with all the testing, but with this change in my branch, it has now been pretty stable again across Linux, Mac, and Windows. If you want to try and extract that out (including my comments) it might be nice to help stabilize mainline for other open PRs, but either way I will be merging #1457 in a couples days as it is pretty much ready, just one little nice to have open item but not a blocker. Would also like to avoid any final merge conflicts on that PR as it has been in the works for a little while. 😮💨 |
|
yeah I saw that change and it confuses me because it shouldn't be necessary. I encountered this issue before and thought I had found a fix. I can't reproduce it locally, so I've been testing in CI. KaiPrince#2 Anyhow if your PR is ready before I end up finding a fix just go ahead with it. If I discover the issue later and I'm able to commit a stable fix I'll make a follow-up PR. This draft PR is just a workbench for me to test in CI. |
|
The hardest part about debugging this is it's so flaky. I thought I had fixed it previously, but turns out it can just pass for no reason. I'm hoping by the time I've figured this out, I've also managed to discover the cause of the flakiness and make it more deterministic. 
|
This reverts commit b1606b8.
|
Okay so this apparently fixed it. For reasons I have yet to understand 
My current theory is it has something to do with the lifetime of the response.clone() object or the async gap. |
Fix the .mp3 tests.
Failing test runs:
https://github.com/KaiPrince/greenwood/actions/runs/17111099878/job/48532445170
#1457 (comment)
Fix: KaiPrince@b133a73