fix current_task() call in example

[belm0]

No description provided.

[codecov]

Codecov Report

Merging #1739 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1739   +/-   ##
=======================================
  Coverage   99.63%   99.63%           
=======================================
  Files         114      114           
  Lines       14427    14427           
  Branches     1104     1104           
=======================================
  Hits        14375    14375           
  Misses         37       37           
  Partials       15       15           

[pquentin]

Thanks!

[pquentin]

test_fail failure, closing/reopening

__________________________________ test_fail __________________________________

    @slow
    async def test_fail():
        async def sleep_4():
            with fail_at(_core.current_time() + TARGET):
                await sleep(100)
    
        with pytest.raises(TooSlowError):
>           await check_takes_about(sleep_4, TARGET)

C:\hostedtoolcache\windows\Python\3.8.5\x64\lib\site-packages\trio\tests\test_timeouts.py:87: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

f = <function test_fail.<locals>.sleep_4 at 0x000002943E665A60>
expected_dur = 1.0

    async def check_takes_about(f, expected_dur):
        start = time.perf_counter()
        result = await outcome.acapture(f)
        dur = time.perf_counter() - start
        print(dur / expected_dur)
        # 1.5 is an arbitrary fudge factor because there's always some delay
        # between when we become eligible to wake up and when we actually do. We
        # used to sleep for 0.05, and regularly observed overruns of 1.6x on
        # Appveyor, and then started seeing overruns of 2.3x on Travis's macOS, so
        # now we bumped up the sleep to 1 second, marked the tests as slow, and
        # hopefully now the proportional error will be less huge.
        #
        # We also also for durations that are a hair shorter than expected. For
        # example, here's a run on Windows where a 1.0 second sleep was measured
        # to take 0.9999999999999858 seconds:
        #   ci.appveyor.com/project/njsmith/trio/build/1.0.768/job/3lbdyxl63q3h9s21
        # I believe that what happened here is that Windows's low clock resolution
        # meant that our calls to time.monotonic() returned exactly the same
        # values as the calls inside the actual run loop, but the two subtractions
        # returned slightly different values because the run loop's clock adds a
        # random floating point offset to both times, which should cancel out, but
        # lol floating point we got slightly different rounding errors. (That
        # value above is exactly 128 ULPs below 1.0, which would make sense if it
        # started as a 1 ULP error at a different dynamic range.)
>       assert (1 - 1e-8) <= (dur / expected_dur) < 1.5
E       assert (1.9288884999999993 / 1.0) < 1.5

C:\hostedtoolcache\windows\Python\3.8.5\x64\lib\site-packages\trio\tests\test_timeouts.py:35: AssertionError
---------------------------- Captured stdout call -----------------------------
1.9288884999999993```

[belm0]

closing/reopening

@pquentin I suggest "Re-run jobs" instead

[pquentin]

@pquentin I suggest "Re-run jobs" instead

Good point! This works on GitHub Actions as it keeps the job history, but not in Travis where it just discards the failing log. (Keeping the log is important to fix flaky tests in the future.)

[pquentin]

Actually, "Re-run jobs" loses the history in GitHub Actions too, so closing/reopening continues to be the better choice.

[belm0]

Close and reopen of issues creates artifacts in the issue history and false notifications. It doesn't seem obviously better.