Closed alexmikoto closed 9 months ago
I think the assumption is that the toolbar will only render completed requests.. so the simplest fix is probably to filter out any request that is in the history list but still active. Possibly this could be done by just not adding it to the history list until the request is complete.
I was about to file an issue over this. I think the proper fix is excluding active requests and @mmerickel commented above, but I think an easier/faster fix would be setting the default total_time
attribute to 0
(or "active" if that works) -- with the intent of allowing the request to appear in the history sidebar, but not cause the rendering error.
I looked into this and it hasn't been an issue for quite a while due to some happenstances in how the server-sent-event logic works. However, I just pushed 6398b099ccfc9a994b3c35048f8b2e3c8f994cc5 which avoids adding the request to the history until it is complete just to make it explicit until someone works on properly supporting showing some data about running requests in the UI.
Without this fix, you have to refresh the toolbar history screen for those old requests to appear because in the history they are considered "old". This ensures they are at the top of the stream when they complete and will automatically appear in the UI.
Apologies my analysis here was wrong, there was a toolbar.visible
attribute added at some point that prevents this from being an issue. I've reverted my change and just added some tweaks in 5bd2ba87f1e24da710f1d9b8c490746b780896be to ensure the request shows up on the UI when it is complete.
Currently the history tab template requires a total_time attribute, however no such attribute exists yet and the rendering aborts with an internal server error.
To replicate make a route that just does an sleep(10) and try to access the debug toolbar before it finishes.