During performance testing I've noticed error messages from AST callbacks like this:

LustreError: 12408:0:(client.c:1164:ptlrpc_import_delay_req()) @@@ IMP_CLOSED   req@ffff880051aa6520 x1551685286400384/t0(0) o104->lustre-MDT0000@0@lo:15/16 lens 296/224 e 0 to 0 dl 0 ref 1 fl Rpc:/0/ffffffff rc 0/-1
LustreError: 12408:0:(client.c:1164:ptlrpc_import_delay_req()) Skipped 2 previous similar messages
LustreError: 12408:0:(ldlm_lockd.c:687:ldlm_handle_ast_error()) ### client (nid 0@lo) failed to reply to blocking AST (req@ffff880051aa6520 x1551685286400384 status 0 rc -5), evict it ns: mdt-lustre-MDT0000_UUID

This happens if client performed some tests actively and was remounted. The reason of this is the old disconnected export which is not yet fully finished while new connection is established already. As result there are locks from that old export and new operations might conflict with some of them, causing blocking AST attempt. When AST request is prepared the ptlrpc_import_delay_req() find its import is in CLOSED state and return -EIO error. Then ldlm_handle_ast_error() consider this as an error and evict old export which is disconnected already.

I think that makes a little sense to perform all these actions, better to recognize that export is failed/disconnected when we found the lock and don't consider it as blocking lock at all.