Only emit permanent errors and otherwise keep retrying#52
Uh oh!
There was an error while loading. Please reload this page.
Conversation
| return; | ||
| } | ||
| if ($sent === false){ |
There was a problem hiding this comment.
Thoughts on removing this block of code all together?
There was a problem hiding this comment.
This is currently required, see the testWriteEmitsErrorWhenResourceIsNotWritable() test case below.
Yes, this code does contain some duplication.
I've intentionally kept this changeset to a minimum in order to ease review. I'll file a second PR to streamline the error handling system after this PR is in.
| $this->assertFalse($buffer->write("bar\n")); | ||
| } | ||
| /** |
There was a problem hiding this comment.
This test currently fails for HHVM: https://3v4l.org/Z1Ft4
Looks like HHVM does allow writing to read-only streams, while Zend does not...
There was a problem hiding this comment.
Looks like this only applies to streams of type MEMORY, i.e. regular file handles work correctly: https://3v4l.org/J467M
There was a problem hiding this comment.
This test will now be skipped on HHVM with a link to this discussion.
This is purely for this very synthetic test case, streams of type MEMORY are not supported by the event loop anyway, so there's no way this could affect a real world program.
Also, streams of type MEMORY are transient (non-permanent) anyway, so there's really little sense in keeping a read-only reference to something that nobody can write to anyway :-)
clue changed the title 
2 participants
Only report errors if nothing could be sent.
Any hard (permanent) error will fail to send any data at all.
Sending excessive amounts of data will only flush some data and then
report a temporary error (EAGAIN) which we do not raise here in order
to keep the stream open for further tries to write.
Should this turn out to be a permanent error later, it will eventually
send nothing and we can detect this.
This fixes a (very sublte) regression introduced via #25.
This also adds a bunch of unit tests so we hopefully no longer rely on any external test cases. The Buffer now has 100% code coverage in our tests.
I've intentionally kept this changeset to a minimum in order to ease review. I'll file a second PR to streamline the error handling system after this PR is in.
Also note that this changeset has an implicit dependency on #51, empty writes would otherwise raise an error event (see that PR for more details).