Issues

PromisingFuture.cancel() does not close context, causing await_children() to loop indefinitely

#97

· coderabbitai opened

on Apr 12, 2026

Flaky timing assertion in test_sync_timeout_spans_multiple_levels_elapsed_time

#96

· coderabbitai opened

on Apr 12, 2026

We need a document outlining which parts/aspects of the framework require consideration of `asyncio` race conditions only and which - of `threading` race conditions too.

#95

· teremterem opened

on Apr 7, 2026

Should we allow or prohibit `PromisingContext` subclasses that extend `asyncio.Future` but not `Promise` ?

question

#94

· teremterem opened

on Apr 6, 2026

Review tests without sync/async counterparts

#92

· teremterem opened

on Mar 30, 2026

Verify AI-applied test renames

#91

· teremterem opened

on Mar 30, 2026

Review and align test naming between sync/async counterparts

#90

· teremterem opened

on Mar 30, 2026

Make sure errors from `Promise.sync()` and/or `PromisingFunction.run()` are informative enough so the user knows when to use which

#88

· teremterem opened

on Mar 26, 2026

Implement disableable thread pool depth check to prevent synchronous promise deadlocks

#87

· coderabbitai opened

on Mar 25, 2026

Migrate from asyncio.coroutines._is_coroutine to inspect.markcoroutinefunction() for Python 3.16+ compatibility

#86

· coderabbitai opened

on Mar 25, 2026

Document convention: PromisingContext is created at call time, not await time

#85

· coderabbitai opened

on Mar 25, 2026

Document convention: PromisingContext must be created at call time, not await time

#84

· coderabbitai opened

on Mar 25, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PromisingFuture.cancel() does not close context, causing await_children() to loop indefinitely

Flaky timing assertion in test_sync_timeout_spans_multiple_levels_elapsed_time

We need a document outlining which parts/aspects of the framework require consideration of `asyncio` race conditions only and which - of `threading` race conditions too.

Should we allow or prohibit `PromisingContext` subclasses that extend `asyncio.Future` but not `Promise` ?

Review tests without sync/async counterparts

Verify AI-applied test renames

Review and align test naming between sync/async counterparts

Make sure errors from `Promise.sync()` and/or `PromisingFunction.run()` are informative enough so the user knows when to use which

Implement disableable thread pool depth check to prevent synchronous promise deadlocks

Migrate from asyncio.coroutines._is_coroutine to inspect.markcoroutinefunction() for Python 3.16+ compatibility

Document convention: PromisingContext is created at call time, not await time

Document convention: PromisingContext must be created at call time, not await time

Search results