`fail_after` deadline is set on initialization not context entry

[zanieb]

Discussed at https://gitter.im/python-trio/AnyIO?at=63ac6d617de82d261600ea24

When using a fail_after context, the deadline is set at "initialization" time rather than __enter__. See

anyio/src/anyio/_core/_tasks.py

Lines 112 to 114 in 0cbb84b

	deadline = (
	(get_async_backend().current_time() + delay) if delay is not None else math.inf
	)

import anyio

async def main():
    ctx = anyio.fail_after(5)
    await anyio.sleep(5)
    with ctx:
        for i in range(1, 6):
            print(i)
            await anyio.sleep(1)

anyio.run(main)

❯ python example.py
1
Traceback (most recent call last):
  File "/Users/mz/dev/prefect/example.py", line 168, in main
    await anyio.sleep(1)
  File "/opt/homebrew/Caskroom/miniconda/base/envs/orion-dev-39/lib/python3.9/site-packages/anyio/_core/_eventloop.py", line 83, in sleep
    return await get_asynclib().sleep(delay)
  File "/opt/homebrew/Caskroom/miniconda/base/envs/orion-dev-39/lib/python3.9/asyncio/tasks.py", line 652, in sleep
    return await future
asyncio.exceptions.CancelledError

Since this is a context manager, the user expectation is that the timer starts when the context is entered.

[zanieb]

This behavior matches trio, I've opened an issue for discussion there: python-trio/trio#2512

[jakkdl]

This was fixed in trio in python-trio/trio#3010

another repro that displays the difference between fail_after and move_on_after

import anyio
import pytest

pytestmark = pytest.mark.anyio
@pytest.mark.parametrize("funcname", [anyio.move_on_after, anyio.fail_after])
async def test_timeout(funcname):
    fa = funcname(3)
    await anyio.sleep(2)
    with fa as cs:
        assert abs(cs.deadline - anyio.current_time() - 3) < 0.1

move_on_after passes, fail_after fails

EDIT: move_on_after fails, fail_after passes

[agronholm]

I would have thought that starting the delay when actually entering the cancel scope is what people would want, given that this is what "after" implies.

[jakkdl]

yes, the problem is that the fail_after deadline starts counting from initialization. Sorry if my message was unclear on that point

[agronholm]

Yeah, good that we're on the same page now :) So I think this behavior may have been unintentional to begin with, and can be fixed.

[agronholm]

I think this was because I didn't imagine someone instantiating these outside of a with statement.

[agronholm]

But wait, isn't the complete opposite true here, given that in fail_after(), the top part is only executed on entering the CM? Thus it's move_on_after() that initializes the deadline on initialization while fail_after() only starts the countdown when entering? What am I missing?

[jakkdl]

we resolved the confusion on Gitter: in the past both fail_after and move_on_after (iirc) was affected, but code changes since has made it such that now only move_on_after is the one misbehaving.