If "explicitly_egress_direct" is True, when a port is deleted, this is treated as "removed" [1]. That means this port won't be processed in [2]. That implies when a port is deleted, the explicit egress flows are left behind in br-int.
If "explicitly_egress_direct" is True, when a port is deleted, as commented in the previous paragraph, the code does not delete the explicit egress flows. But could happen that this method could be called in the first polling cycle because the OVS agent has detected there is a deleted port. Then the OVS agent RPC server receives the port delete call [3], but this deleted port is treated in the next polling cycle. The "port_info" variable does not contain the deleted port (treated in the previous cycle). The code in [2] tries to read the port from the OVS DB, but is not there anymore and the OF deletion commands fail.
This is related to https://bugs.launchpad.net/neutron/+bug/1732067 and https://review.opendev.org/#/q/efa8dd08957b5b6b1a05f0ed412ff00462a9f216.
[1]https://github.com/openstack/neutron/blob/8575f60e86029cd91d5fa6f6be4596a22b1ee35b/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L676
[2]https://github.com/openstack/neutron/blob/8575f60e86029cd91d5fa6f6be4596a22b1ee35b/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L685-L695
[3]https://github.com/openstack/neutron/blob/8575f60e86029cd91d5fa6f6be4596a22b1ee35b/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L625-L628
we also saw the same issue there, but we have submitted the code, not sure why it isn't merged yet. the removed port info can be gotten from l3_pop rpc.