Repository navigation
asyncua.common.subscription | Task-9 | Received a notification for unknown handle: - when does this happen?
#2036
Answered
by
yudin-s
iamthebull
asked this question in
Q&A
|
Under what circumstances does this error occur? I'm getting it immediately after removing a monitored item using Should I be concerned about this? The one difference I do notice is that above there is a Edit: I was able to reproduce. import asyncio
import logging
from asyncua.client.client import Client
from asyncua.ua import NodeId, Int16, String
from asyncua.common.subscription import DataChangeEvent, StatusChangeEvent, Subscription
logging.basicConfig(level=logging.INFO, filename='log/client-example2.log', filemode='w')
_logger = logging.getLogger("asyncua")
async def subscription_handler(subscription: Subscription):
try:
async for event in subscription:
match event:
case DataChangeEvent(node=node, value=value):
_logger.info("data change %r %s", node, value)
case StatusChangeEvent(notification=notif):
_logger.info("status change %s", notif.Status)
except Exception as e:
_logger.exception(f"error in subscription handler - {e}")
async def main() -> None:
"""
Run against examples/server-example.py
"""
async with asyncio.TaskGroup() as tg:
async with Client(
url="opc.tcp://localhost:4840/freeopcua/server/",
auto_reconnect=True,
reconnect_max_delay=2.0) as client:
idx = await client.get_namespace_index(uri="http://examples.freeopcua.github.io")
var = await client.nodes.objects.get_child(f"{idx}:MyObject/{idx}:MyVariable")
sub = await client.create_subscription(2000)
sub_task = tg.create_task(subscription_handler(sub), name='subscription handler')
handle = await sub.subscribe_data_change(var)
await asyncio.sleep(1)
await sub.unsubscribe(handle)
await asyncio.sleep(1)
sub_task.cancel()
if __name__ == "__main__":
try:
asyncio.run(main())
except KeyboardInterrupt:
passoutput: |
Answered by
yudin-s
Sep 4, 2026
Replies: 1 comment
|
Yes, the In asyncua, So in the sequence from your log:
That is usually not dangerous if it happens only immediately after unsubscribe. It means a late queued notification for an item you just deleted was discarded, not that asyncua delivered data to the wrong subscription. I would be concerned only if one of these is true:
For normal unsubscribe cleanup, ignoring it is fine. If you want to avoid the warning/noise in a shutdown path, deleting the whole subscription with If this explains the post-unsubscribe warning, please mark the answer as solved. |
0 replies
Answer selected by
iamthebull
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yes, the
PublishResultarriving afterdelete_monitored_itemsis the relevant part here.In asyncua,
unsubscribe(handle)sendsDeleteMonitoredItems, checks the result, then removes the local mapping from client handle toSubscriptionItemData. Later,publish_callback()explodes the server notification data. If a queuedDataChangeNotificationstill contains the oldClientHandleand the local mapping has already been removed,_explode_datachange()logsReceived a notification for unknown handleand drops that item.So in the sequence from your log:
DeleteMonitoredItemsfor server monitored item112;StatusCode(value=0)for the delete;