feat: handle CancelledError - cancel if no other waiters

[BobTheBuidler]

What do these changes do?

Currently if a decorated function is awaited, and then that task is cancelled, async_lru will never cancel the task, potentially leading to memory leaks and other fun things.

In cases where the only waiter is cancelled, this PR will gracefully cancel the task and pop the key

Are there changes in behavior for the user?

Yes, a cancelled task will cancel any cached jobs that haven't completed and have no other waiters.

Related issue number

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes

[Dreamsorcerer]

Looks like a good idea. Should get a test added that reproduces the issue.

[BobTheBuidler]

I've added the tests and this is now ready for review.

But post-review, let's make sure we merge #688 before this one so we can start populating data in the codspeed dashboard

[codspeed-hq]

CodSpeed Performance Report

Merging #697 will not alter performance

_{Comparing BobTheBuidler:patch-3 (c29b492) with master (2913fe2)}

Summary

✅ 39 untouched

[BobTheBuidler]

Looks like there's one complication I didn't consider

If the cancelled waiter is the first waiter for a particular cache item, cancelling is easy because the waiter already has the task (it created the task)

But if any subsequent waiter is cancelled, that waiter did not create the task and does not have any reference to it. Only the CacheItem's fut.

is there any reason the tasks need to go in __tasks or is that just a common place for collection? Would it be acceptable to instead add a task field to the CacheItem dataclass and have the _task_done_callback remove it from there instead of using the current __tasks set?

That way, each CacheItem would be directly linked to its associated task and any waiter would have access to it for cancellation.

[Dreamsorcerer]

is there any reason the tasks need to go in __tasks or is that just a common place for collection?

Not sure. If the tests are passing, then another approach may be fine.

Would it be acceptable to instead add a task field to the CacheItem dataclass and have the _task_done_callback remove it from there instead of using the current __tasks set?

I guess as long as we don't end up with circular references or anything that might causes memory leaks, then it might work.