Timeout for async_write, which must not happen at all about beast HOT 7 OPEN

Calling basic_stream::expires_after while there is a pending write operation, does not update the write timer:
https://github.com/boostorg/beast/blob/develop/include/boost/beast/core/impl/basic_stream.hpp#L814

Because of response_queue_ every time you call expires_after (except the first time) there is a pending write operation which prevents updating the write timer.

If you change queue_limit to 1, you will observe that the timeout does not occur. An easy fix would be to call expires_after before initiating the write operation, as that is the only place where you can be confident that there is no pending write operation.

By the way, I believe we should update the documentation for basic_stream::expires_after and basic_stream::expires_at to mention this behavior.

from beast.

For me it is surprising from the user's point of view, because a timeout simply occurs after a certain time, even though there are ALWAYS read and write operations. There is no period of time in which nothing happens, so that a timeout for anything at all would be justified.

from beast.

An easy fix would be to call expires_after before initiating the write operation, as that is the only place where you can be confident that there is no pending write operation.

from beast.

I have already mentioned this in my request. But this is more of a workaround for me.

from beast.

The reason you can't update the write timer while it is pending is because it has already initiated an async_wait operation on that timer (with whatever timeout value was set). Therefore, updating it would be logically incorrect and more surprising for users.

Could you please provide more context or clarify the specific logic or behavior you want to implement? You might consider updating a time point inside on_read operation an use basic_stream::expires_at interface with the time offset you need before calling async_write.

from beast.

I just wanted to report this behavior, because according to the documentation it sounded to me like the timer should have been reset automatically with the next async_read(...). It was not clear to me that the write timeout would not be reset.

"The timer applies collectively to any asynchronous reads or writes initiated after the expiration is set, until the expiration is set again"

from beast.

Maybe each async method could pull the last set expiry time, when it was not possible to set it before because of pending?
Here is some pseudo code (mutexes may or may not also be required) for the idea...unfortunately I hardly know boost:

std::atomic_bool read_expiry_time_set_is_pending{ false };
std::atomic_bool write_expiry_time_set_is_pending{ false };
std::atomic< net::steady_timer::duration > lastSetExpiryTime;


basic_stream<Protocol, Executor, RatePolicy>::
expires_after(net::steady_timer::duration expiry_time)
{
	//Add this at top
	lastSetExpiryTime.store( expiry_time );
	read_expiry_time_set_is_pending  = impl_->read.pending;
	write_expiry_time_set_is_pending = impl_->write.pending;

	...	
	...	
}


async_read( ... )
{
	//Add this at top
	if (read_expiry_time_set_is_pending)
	{
		read_expiry_time_set_is_pending = false;
		BOOST_VERIFY(impl_->read.timer.expires_after(lastSetExpiryTime.load()) == 0);
	}
	
	...
	...
}

async_write( ... )
{
	//Add this at top
	if (write_expiry_time_set_is_pending)
	{
		write_expiry_time_set_is_pending = false;		
		BOOST_VERIFY(impl_->write.timer.expires_after(lastSetExpiryTime.load()) == 0);
	}
	
	...
	...
}

from beast.