ClientRequestState treats "eos" as a terminal state and won't transition to EXCEPTION or CANCELLED out of it. See the below code snippet from ClientRequestState::Cancel():
If the cancellation is initiated by the server (e.g. because of query_timeout_s or exec_time_limit_s) then we should arguably treat that as an exception and put the query into the EXCEPTION state (because it is not a user-initiated cancellation) if it is not already in an EXCEPTION or CANCELLED state. That way the client can see that the expiry happened and access the cause of expiry.
One argument against using the EXCEPTION state is that admins or users might think that something went wrong and needs to be investigated, see
A separate issue is that user-initiated cancellation should use the CANCELLED state: IMPALA-1262