Clients can fail with authorization errors after ACL's updated in console

Problem Statement 

After a users ACL's have been updated in Redpanda Console,   kafka clients can report authorization errors despite having the required ACL's to access the resource.

 

Detail

Clients will reported authorization errors such as  (message depends on client type used ) 

Not authorized to read from partition topic-1-0. org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized

Redpanda reports :

INFO 2024-04-16 11:43:10,200 [shard 0:fetc] kafka - 10.10.10.10:62370 failed authorization - connection_context.cc:179 - proto: kafka rpc protocol, sasl state: complete, acl op: read, principal: type {user} name {redpanda-chat-account}, resource: {topic1}

Cause

In the current implementation of Console, when it performs an update of a users ACL's , 
(for example adding an additional topic resource)

It does the following :
-Makes an internal copy of the users current ACL's
-Deletes the users existing ACL's
-Recreates the ACL's from the internal copy with any additional ACL's that were added (or removes)

Depending on timings,  kafka clients can then encounter authorization errors at the point console deletes them.  

Solution/Workaround 

The following  issue has been logged for Console to change the way it handles ACL updates:
Change ACL modification mechanism in Console #1220 and fixed in Console releases 2.7.1 and higher