I have had this problem in several different projects with different teams.
I generally think of it as the "code hostage" or "cherry-picking" problem. You have the work of 15 issues reviewed and merged and loaded up and running on a test environment. For 14 of those issues, a "user" ( or whatever you call the non-developer issue-owner in this case ) checks in and says it is good. Time is passing and the 15th person is a no-show. It's worse than if they said it still wasn't fixed -- then you would immediately go to work reverting that code change and re-testing everything -- but instead everything is held up in limbo.
One way to address the majority of these issues, is to set up a separate testing environment or server per ticket, and put the pull request or branch on it, before it is merged to the main branch. Force users to test BEFORE it gets on the path that will end up in a deployment. This means that slow moving people won't block others.
This might seem expensive, but with APIs to cloud hosting and/or container technology, it can be automated, and is a lot cheaper than it would have been a few years ago.
You can still end up with a problem on the now integrated code, and still have to cherry-pick / revert some commits, and since the result has not yet been tested all together, you still have to re-test. However this happens much less often, because it is only happening in the cases where interaction between different work is causing the problem.