Comment 4 for bug 1938766

I think I've figured out what's causing the issue.

Ultimately, it is a race condition with the order of messages from the ovsdb-server. There is the Idl's monitor request where it gets a stream of updates when the database is changed, and there are also the replies to individual transactions.

When doing an OVSDB insert, you assign a temporary UUID to the object you are creating and then after the server inserts it, its reply will include the permanent UUID that it chose for the object.

ovsdbapp's AddCommand, which PgAddCommand subclasses, in post_commit() calls txn.get_insert_uuid(self.result) which allows us to get the real UUID from the server. This will always be available because it comes from the reply to the transaction which just committed. The problem is that we try look up and the row in memory with this UUID, but if we haven't already gotten the *monitor request notification* for that row, it will not be found and we will get the KeyError.

It doesn't look easy to solve this in python-ovs, because we don't have access to the full Row object when processing the insert operation's reply--it just contains the UUID. I believe I can work around this in ovsdbapp w/o changing the API by storing the temporary Row object when saving the result and then adding the ability to override the uuid presented in the RowView result.