Skip to content

Addresses #24291 #24452

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

Closed
wants to merge 1 commit into from
Closed

Conversation

einar-hjortdal
Copy link
Contributor

Seems to solve the issue, can't find negatives.
I am not the author of BufferedReader, I do not know what the purpose of the check was.
Adding a test to prevent a regression would be nice, but I do not know what causes the issue in the first place.

Copy link

Connected to Huly®: V_0.6-22822

@spytheman
Copy link
Member

Adding a test to prevent a regression would be nice, but I do not know what causes the issue in the first place.

If you do not know what the cause of the issue is, and can not make a test, how are you sure, that you have fixed it, and that your changes would not regress or cause problems for others?

@einar-hjortdal
Copy link
Contributor Author

einar-hjortdal commented May 11, 2025

I have investigated this issue. The way I discovered it is by talking to a server that disconnects unexpectedly. When the server disconnects, you would expect Eof to be returned when attempting to read, instead I got Unexpected.
This is because instead of reaching Eof, the algorithm was just wrongly handling read attempts from the underlying TCPConn reader, returning Unexpected immediately when getting no data, instead of trying to get data a second time and reaching Eof.
Now I know that when I am getting Unexpected, the error is actually a Eof. I have reported the error and provided a fix, which admittedly looks rough, but seems to work correctly. Other than testing changes with a real service, I don't know how to write a test for it.
I will also be testing a little more, up until tuesday.

@spytheman
Copy link
Member

I do not want to merge it without a test, since this part of the code is brittle and already had a period of instability, where different people wanted different behaviors.

See the existing vlib/io/reader_test.v as an example on how to create a struct instance of the interface, that you can later control in whatever ways you need to simulate the situation you were in, without having to re-create a real service.

@einar-hjortdal
Copy link
Contributor Author

I do not want to merge it without a test, since this part of the code is brittle and already had a period of instability, where different people wanted different behaviors.

I agree, however, I do not know when I'll have time to write a test.
For now, a user can assume that Unexpected is actually Eof.

@spytheman spytheman marked this pull request as draft May 21, 2025 03:13
@spytheman
Copy link
Member

@einar-hjortdal do you have a way to test it now?

@einar-hjortdal
Copy link
Contributor Author

@einar-hjortdal do you have a way to test it now?

No, I'm sorry, I do not have time to work on this.

@spytheman
Copy link
Member

spytheman commented Jul 5, 2025

No, I'm sorry, I do not have time to work on this.

Thanks for the PR, but without a test, I will not merge it unfortunately, and since you do not have time, its status is unlikely to change.

Hopefully in the future, there will be an opportunity to find a more reproducible way to reveal the problem, if it exists, and add a fix + test for it.

I am closing it for now.

@spytheman spytheman closed this Jul 5, 2025
@einar-hjortdal
Copy link
Contributor Author

The problem does exist; it is clear if you read the source code. What matters is that users are informed that the Unexpected error is Eof and not something else.

@spytheman
Copy link
Member

I've read the source code and your patch, and I could not infer a test that would reproduce the problem that you saw.

To me, that means that the problem is not clear, or I would have added the test myself a long time ago, and this would not have waited in a limbo for 2 months.

-> I wanted a test from you, in order to prevent future regressions, as I already stated above. If you do not have time to make it, and if there is not some other developer that can, that understands it better than me, and has more time than you, I do think it is better, to have this closed, and wait until there is a better reproduction/fix.

@einar-hjortdal
Copy link
Contributor Author

Just to be clear, the issue is here:
this line calls fill_buffer, which reads 0 bytes here without returning any error, therefore function execution continues and the failure is marked at this line, but because there is no loop, the function returns true wrongly assuming it got data, and this causes the caller to return the error instead of attempting another read and returning Eof

@spytheman
Copy link
Member

ok, hopefully that explanation, clears it up for the developer that will write the test, and we could then reopen the PR or make a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants