Reset responseBuffer on error, close, and new connections #19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After writing #18 (comment) , I realized that it didn't really sit right with me.
Digging in, I discovered that the reason was that the responseBuffer isn't cleared on reconnect. All future data from future connections gets appended to the "ERROR Too many open connections\r\n" string (length 33). If the buffer is exactly that string, we throw an error, otherwise (like if the contents are "ERROR Too many open connections\r\nERROR Too many open connections\r\n" or the error message and the start of a valid response) we parse it as a regular message (same behavior as before my prior PR). Unfortunately, the first 24 bytes of that error string parse as a response header:
We then hit https://github.com/makenotion/memjs/blob/efce2ebd228bfcb4f51905dce4a020c8a08e52b3/src/memjs/utils.ts#L154C1-L156
which means that we will wait until dataBuf is 1864396129 (totalBodyLength) + 24 bytes long (1.73GiB). We still have the close handler and the timeout handlers will trigger and clear the queue, but the buffer state will never reset. Client is forever poisoned.
We really need to rework the socket handling and connection reset logic holistically, but that's more of a lift and really would be best under exhaustive testing.
verified after the fix: