)]}'
{"ovsdbapp/backend/ovs_idl/connection.py":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"c7f53a09f271909d7b9285d470e74c7190917d39","unresolved":true,"context_lines":[{"line_number":77,"context_line":"        self.idl \u003d idl"},{"line_number":78,"context_line":"        self.thread \u003d None"},{"line_number":79,"context_line":"        self.is_running \u003d None"},{"line_number":80,"context_line":"        self._last_has_lock \u003d False"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    def __del__(self):"},{"line_number":83,"context_line":"        self.txns.close()"}],"source_content_type":"text/x-python","patch_set":1,"id":"858a728d_32fd7e35","line":80,"range":{"start_line":80,"start_character":0,"end_line":80,"end_character":35},"updated":"2026-08-18 19:34:35.000000000","message":"Since I know the problem I know at this point this lock is unrelated to the RLock on L76 but I will definitely not know in a year from now :) Maybe we should distinguish the two.\n\nAlso looking at the method `def _check_lock_change(self):` we\u0027re only dealing with `self._last_has_lock` and `self.idl` which makes me think if the method should be moved to the `OvsdbIdl` class?","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"},{"author":{"_account_id":5756,"name":"Terry Wilson","email":"twilson@redhat.com","username":"otherwiseguy"},"change_message_id":"ab36bbff36bf531ee9da021d00b0385d74ead89a","unresolved":true,"context_lines":[{"line_number":77,"context_line":"        self.idl \u003d idl"},{"line_number":78,"context_line":"        self.thread \u003d None"},{"line_number":79,"context_line":"        self.is_running \u003d None"},{"line_number":80,"context_line":"        self._last_has_lock \u003d False"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    def __del__(self):"},{"line_number":83,"context_line":"        self.txns.close()"}],"source_content_type":"text/x-python","patch_set":1,"id":"8a90ad29_776e4277","line":80,"range":{"start_line":80,"start_character":0,"end_line":80,"end_character":35},"in_reply_to":"858a728d_32fd7e35","updated":"2026-08-19 13:43:29.000000000","message":"Nothing has to use OvsdbIdl, plenty of people just pass in idl.Idl to Connection. This is why eventually I want the real Idl from OVS to have the notify_lock method and not do it here (though we will actually still have to queue it to the RowEventHandler and ensure that the event cannot fire before the db dump).\n\nI\u0027m open to recommendations for the distinguishing. \"lost has_lock\" to me distinguishes it from a python lock, but that\u0027s because I\u0027m intimately familiar with python-ovs. :) Is a code comment sufficient?","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"c7f53a09f271909d7b9285d470e74c7190917d39","unresolved":true,"context_lines":[{"line_number":150,"context_line":"        if self.idl.has_lock \u003d\u003d self._last_has_lock:"},{"line_number":151,"context_line":"            return"},{"line_number":152,"context_line":"        self._last_has_lock \u003d self.idl.has_lock"},{"line_number":153,"context_line":"        notify_lock \u003d getattr(self.idl, \u0027notify_lock\u0027, None)"},{"line_number":154,"context_line":"        if notify_lock is not None:"},{"line_number":155,"context_line":"            notify_lock(self.idl.lock_name, self.idl.has_lock)"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"15eb8362_e192ced6","line":153,"updated":"2026-08-18 19:34:35.000000000","message":"the `notify_lock` is on the RowEventHandler instance, not the `idl`. Shouldn\u0027t it be\n\n```\nhandler \u003d getattr(self.idl, \u0027notify_handler\u0027, None)\nif handler:\n    handler.notify_lock(...)\n```\n?","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"},{"author":{"_account_id":5756,"name":"Terry Wilson","email":"twilson@redhat.com","username":"otherwiseguy"},"change_message_id":"ab36bbff36bf531ee9da021d00b0385d74ead89a","unresolved":true,"context_lines":[{"line_number":150,"context_line":"        if self.idl.has_lock \u003d\u003d self._last_has_lock:"},{"line_number":151,"context_line":"            return"},{"line_number":152,"context_line":"        self._last_has_lock \u003d self.idl.has_lock"},{"line_number":153,"context_line":"        notify_lock \u003d getattr(self.idl, \u0027notify_lock\u0027, None)"},{"line_number":154,"context_line":"        if notify_lock is not None:"},{"line_number":155,"context_line":"            notify_lock(self.idl.lock_name, self.idl.has_lock)"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"51f1590b_e8a7857c","line":153,"in_reply_to":"15eb8362_e192ced6","updated":"2026-08-19 13:43:29.000000000","message":"This is mirroring how notify() works with RowEventHandler, i.e. we override noitfy() on the Idl or assign the RowEventHandler.notify to the Idl.\n\nIn this case, it looks weird because there is not (yet) a notify_lock() method in upstream OVS. But my intention is that there will be.\n\nI left it this way despite the weirdness because it also gives us the ability to *not* queue lock events if we aren\u0027t interested in them, which handler.notify() does. At the very least it\u0027s worth a comment here (I did comment on it in handler.notify() docstring.","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"}],"ovsdbapp/backend/ovs_idl/idlutils.py":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"bfae21d18d3b10043f030c17dfb7ddad7fcd790d","unresolved":true,"context_lines":[{"line_number":236,"context_line":"def wait_for_change(_idl, timeout\u003dNone, seqno\u003dNone):"},{"line_number":237,"context_line":"    \"\"\"Wait for change_seqno to advance past seqno and the DB dump to complete"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"    IDL_S_MONITORING is an additional gate, not a replacement for the"},{"line_number":240,"context_line":"    change_seqno check: on connect a lock grant bumps change_seqno before the"},{"line_number":241,"context_line":"    monitor reply, so gating on change_seqno alone returns against an empty"},{"line_number":242,"context_line":"    cache. It\u0027s a no-op for a caller already monitoring (e.g. a txn retry)."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"    :param _idl: The Idl instance"},{"line_number":245,"context_line":"    :type _idl: ovs.db.idl.Idl"}],"source_content_type":"text/x-python","patch_set":1,"id":"45e647d4_8a84fa45","line":242,"range":{"start_line":239,"start_character":0,"end_line":242,"end_character":75},"updated":"2026-08-18 19:41:06.000000000","message":"Is it related to this patch?","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"},{"author":{"_account_id":5756,"name":"Terry Wilson","email":"twilson@redhat.com","username":"otherwiseguy"},"change_message_id":"ab36bbff36bf531ee9da021d00b0385d74ead89a","unresolved":true,"context_lines":[{"line_number":236,"context_line":"def wait_for_change(_idl, timeout\u003dNone, seqno\u003dNone):"},{"line_number":237,"context_line":"    \"\"\"Wait for change_seqno to advance past seqno and the DB dump to complete"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"    IDL_S_MONITORING is an additional gate, not a replacement for the"},{"line_number":240,"context_line":"    change_seqno check: on connect a lock grant bumps change_seqno before the"},{"line_number":241,"context_line":"    monitor reply, so gating on change_seqno alone returns against an empty"},{"line_number":242,"context_line":"    cache. It\u0027s a no-op for a caller already monitoring (e.g. a txn retry)."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"    :param _idl: The Idl instance"},{"line_number":245,"context_line":"    :type _idl: ovs.db.idl.Idl"}],"source_content_type":"text/x-python","patch_set":1,"id":"e9979278_4e5d5cf5","line":242,"range":{"start_line":239,"start_character":0,"end_line":242,"end_character":75},"in_reply_to":"45e647d4_8a84fa45","updated":"2026-08-19 13:43:29.000000000","message":"Yes. Without it you can be notified of a lock *before getting the db dump*. And then your reconcile() method that fires on getting the lock syncs across an empty DB.","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"}],"ovsdbapp/event.py":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"bfae21d18d3b10043f030c17dfb7ddad7fcd790d","unresolved":true,"context_lines":[{"line_number":32,"context_line":"STOP_EVENT \u003d (\"STOP\", None, None, None)"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"# Queued representation of a lock acquire/lose, dispatched by notify_loop."},{"line_number":35,"context_line":"# It is a namedtuple (and therefore a tuple), but its type distinguishes it"},{"line_number":36,"context_line":"# from the 4-tuple row notifications and from STOP_EVENT, so lock transitions"},{"line_number":37,"context_line":"# ride the same notify_loop thread as row events without being mixed."},{"line_number":38,"context_line":"LockNotification \u003d collections.namedtuple("}],"source_content_type":"text/x-python","patch_set":1,"id":"7d88d714_c2014c52","line":35,"updated":"2026-08-18 19:41:06.000000000","message":"yeah, I\u0027m not sure I like it. I don\u0027t have a better solution for this yet but I think it would be better if we could somehow make it compatible with this interface? Maybe having the lock routines as two events - one for acquire and one for lose. It just wouldn\u0027t be a \"row\" event?","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"},{"author":{"_account_id":5756,"name":"Terry Wilson","email":"twilson@redhat.com","username":"otherwiseguy"},"change_message_id":"ab36bbff36bf531ee9da021d00b0385d74ead89a","unresolved":true,"context_lines":[{"line_number":32,"context_line":"STOP_EVENT \u003d (\"STOP\", None, None, None)"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"# Queued representation of a lock acquire/lose, dispatched by notify_loop."},{"line_number":35,"context_line":"# It is a namedtuple (and therefore a tuple), but its type distinguishes it"},{"line_number":36,"context_line":"# from the 4-tuple row notifications and from STOP_EVENT, so lock transitions"},{"line_number":37,"context_line":"# ride the same notify_loop thread as row events without being mixed."},{"line_number":38,"context_line":"LockNotification \u003d collections.namedtuple("}],"source_content_type":"text/x-python","patch_set":1,"id":"9a5ef489_8fe92c53","line":35,"in_reply_to":"7d88d714_c2014c52","updated":"2026-08-19 13:43:29.000000000","message":"I felt similiarly, and already tried it. It\u0027s much worse. You have to fake Rows that are passed to match_fn, etc. because they will die on row\u003dNone, etc. Locks are an inherently different notification stream.","commit_id":"bb11a307c04dd18850e6a65518fd6fdcb0a92024"}]}