forked from goodboy/tractor
Don't (noisly) log about runtime cancel RPC tasks
Since in the case of the `Actor._cancel_task()` related runtime eps we actually don't EVER register them in `Actor._rpc_tasks`.. logging about them is just needless noise, though maybe we should track them in a diff table; something like a `._runtime_rpc_tasks`? Drop the cancel-request-for-stale-RPC-task (`KeyError` case in `Actor._cancel_task()`) log-emit level in to `.runtime()`; it's generally not useful info other then for granular race condition eval when hacking the runtime.runtime_to_msgspec
parent
a1b124b62b
commit
2db03444f7
|
@ -397,12 +397,18 @@ async def _errors_relayed_via_ipc(
|
|||
f'|_{ctx._task}\n'
|
||||
f' >> {ctx.repr_rpc}\n'
|
||||
)
|
||||
else:
|
||||
log.cancel(
|
||||
'Failed to de-alloc internal runtime cancel task?\n'
|
||||
f'|_{ctx._task}\n'
|
||||
f' >> {ctx.repr_rpc}\n'
|
||||
)
|
||||
# TODO: remove this right? rn the only non-`is_rpc` cases
|
||||
# are cancellation methods and according the RPC loop eps
|
||||
# for thoses below, nothing is ever registered in
|
||||
# `Actor._rpc_tasks` for those cases.. but should we?
|
||||
#
|
||||
# -[ ] maybe we should have an equiv `Actor._runtime_rpc_tasks`?
|
||||
# else:
|
||||
# log.cancel(
|
||||
# 'Failed to de-alloc internal runtime cancel task?\n'
|
||||
# f'|_{ctx._task}\n'
|
||||
# f' >> {ctx.repr_rpc}\n'
|
||||
# )
|
||||
|
||||
finally:
|
||||
if not actor._rpc_tasks:
|
||||
|
|
|
@ -1256,9 +1256,10 @@ class Actor:
|
|||
# - child returns a result before cancel-msg/ctxc-raised
|
||||
# - child self raises ctxc before parent send request,
|
||||
# - child errors prior to cancel req.
|
||||
log.cancel(
|
||||
'Cancel request invalid, RPC task already completed?\n\n'
|
||||
f'<= canceller: {requesting_uid}\n\n'
|
||||
log.runtime(
|
||||
'Cancel request for invalid RPC task.\n'
|
||||
'The task likely already completed or was never started!\n\n'
|
||||
f'<= canceller: {requesting_uid}\n'
|
||||
f'=> {cid}@{parent_chan.uid}\n'
|
||||
f' |_{parent_chan}\n'
|
||||
)
|
||||
|
|
Loading…
Reference in New Issue