-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix history loading when state was corrupt/non-existent #5946
Conversation
I wish there was a better way to know if state should be restored, so we could at least do a |
If the event stream has events, it should have state. I'm not sure how we are going to do with conversations, do they share the same stream? Then we don't know from the existence of the stream alone. Otherwise, I think that suffices. |
@openhands-agent Read this PR and understand its diff. Then run the project's unit tests, and fix them if they fail. You know how to set up the unit tests for this particular project. |
Overview of Changes:
Current Status: No remaining issues identified. All tests are passing and the implementation now follows better practices with proper Docker API usage and mocking. |
End-user friendly description of the problem this fixes or functionality that this introduces
Fix history loading when state was corrupt or not saved properly (such as on a runtime error)
This PR proposes a fix for history lost on runtime errors:
When the session is restored, the history is initialized from the event stream, but that depended on whether there was a valid State restored. That doesn't make a lot of sense, and it meant that when the execution failed with a runtime error or something bad enough that it didn't get to save the State or the file is corrupt, history was not loaded from the stream. This PR fixes that.
Link of any specific issues this addresses
Fix #5602
To run this PR locally, use the following command: