Convention to Document
Context: Raised in PR #79 (comment: #79 (comment)), requested by @teremterem.
Convention
All decorated functions that result in PromisingContext creation (e.g. @promising.context, @promising.function) must create their contexts at call time, not at await time.
Rationale
- Ensures a consistent approach to context hierarchy formation across the entire framework.
- For
@promising.function, await time is unpredictable (callers may await a Promise long after calling the decorated function), so deferring context creation to await time would make parent/loop resolution non-deterministic.
- Keeps the parent-child relationship stable and predictable: the context hierarchy reflects the call graph, not the await graph.
Action Required
Add documentation of this convention to the project documentation (e.g. README.md, CONTRIBUTORS.md, or a dedicated architecture/conventions doc), so future contributors and reviewers are aware of this design decision and its rationale.
References
Convention to Document
Context: Raised in PR #79 (comment: #79 (comment)), requested by @teremterem.
Convention
All decorated functions that result in
PromisingContextcreation (e.g.@promising.context,@promising.function) must create their contexts at call time, not at await time.Rationale
@promising.function, await time is unpredictable (callers may await a Promise long after calling the decorated function), so deferring context creation to await time would make parent/loop resolution non-deterministic.Action Required
Add documentation of this convention to the project documentation (e.g.
README.md,CONTRIBUTORS.md, or a dedicated architecture/conventions doc), so future contributors and reviewers are aware of this design decision and its rationale.References
PromisingContext::get_trace()#79PromisingContext::get_trace()#79 (comment)