Prevent leaky abstraction when using async

Question

I have a controller that suppose to run the import. The importing process might take a long time so I have decided to use a message queue (async). I have created a wrapper interface that has a method import to encapsulate the implementation. From the controller's perspective it shouldn't care how it is imported (whether straight away or async). But the original code can throw exceptions and if it is async then there is no way to catch these exceptions in the controller.

public function execute()
{
    try {
        $this->importer->import();
        $this->messageManager->addSuccessMessage(__('The import has been successfully performed.'));
    } catch (Exception $e) {
        $this->logger->error($e->getMessage());
    }

I mean the problem is that if I swap the async importer with the original one, we can know whether it will succeed or fail. But when we use the async one then code can't simply just output "the import has been successful", nor can it output "the import has been scheduled" because it is an implementation detail leak.

Any recommendations on how to solve this problem?

Update: I assume these are two different responsibilities:

1. Import
2. Schedule the import

So I guess they are not interchangeable at all.

Answer 1

So after a thorough thought I have concluded that running the script and scheduling it are two separate actions. Originally I though they should differ only in the scope of implementation detail; I fell into this trap because the cron that is reading that MQ is running every minute so the execution of the scheduled script seems like is running almost instantly, just like it would if it would be run directly.

So with this conclusion I have decided to make a step further and renamed the whole thing into "schedule operation" instead of "run operation". I guess the user needs to know that it is going to be scheduled instead of just run. And if the user is confused and asks WTF? Why cannot it just run instead? Then somebody could answer: well, scheduling is better than running because of A, B and C.