I don’t know anything about the ‘bug’ you’re referring to here… but just to clarify a few things.
That condition IS evaluated sever-side.
There is NO difference between Current User Role Is Admin
and Current User is Logged In And Current User Role Is Admin
in terms of where the condition is evaluated (sever or client).
Current User is Logged In
can be manipulated on the client just as easily as Current User Role is Admin
, for use in client-side action conditions.
(so too can search for users count > 0
)
Client-side actions based on data that’s already loaded on the page will evaluate conditions based on that client-side version of the data.
(note: conditions for client-side actions which involve data NOT already loaded to the page will first load the relevant data to the page BUT the conditions will be evaluated on the client-side, so that data is still open to manipulation)
But all that’s irrelevant, as server-side actions evaluate data for conditions on the sever, and so are immune to any client-side manipulation.
i.e. Current User's Role is Admin
is evaluated on the Sever, just the same as Current User is Logged In and Current User's Role is Admin
when being used as a condition on a server-side action (or a WF that contains server-side actions).
So there should be no difference in the WU cost between those 2 conditions.
I just ran another test to confirm this, this time using Current User is Logged In and Current User's Role is Admin
and got exactly the same results as before (as expected)…
i.e. again, as expected, for a client-side only WF there is NO additional WU cost to evaluate the condition, as the User data is already on the page.
For a WF with sever-side actions, a WU of 0.02 is incurred which, again, is exactly what’s expected to retrieve the relevant User data in order to evaluate it.
If you’re seeing different results to that, then I suspect there is some other source of the WU coming into play here.

That bug is if you use the condition
current user is logged in and current user role is admin
in order to force a server side evaluation (whether there are server side actions or not in the event series),
Your assumption that using current user is logged in and current user role is admin
somehow forces the condition to be evaluated on the sever (whether there are server-side actions or not) is simply untrue (and easily testable).
As I’ve explained client-side WF actions will evaluate any data-based conditions against the client-side versions of that data. (e.g. the condition current user is logged in and current user role is admin
is evaluated client-side for any client-side actions in the WF).
Server-side actions always evaluate conditions on the server (unless they are based on conditions the server doesn’t have access to).
It’s just as easy to manipulate the Current User is logged in
condition on the client side as it is to manipulate Current User's role is Admin
.
But, again, that only affects client-side actions.