Test Your Asynchronous Task

00:00 Testing your asynchronous task.

00:04 When you start a Celery worker, it loads the code into memory. When it receives a task through the message broker, it will execute that code. Because of that, you need to restart your Celery worker every time you change the code.

00:17 To avoid manually restarting your Celery worker on every code change during development, you can set up auto-reload using watchdog or by writing a custom management command.

00:27 But in this case, you’ll take the simpler route of closing your current Celery worker and restarting it.

00:34 Open the terminal window where you’re running the Celery worker and stop execution by pressing CTRL+C.

00:42 Then restart the worker with the same command you used previously and add -l info to set the log level to info. This will mean you’ll see more information printed to the terminal

00:58 on startups Celery displays all tasks that are discovered in the tasks section. This output confirms that Celery has registered send_feedback_email task, and is ready to handle incoming messages related to this task.

01:12 With all services up and running and the code refactored for Celery, you are ready to step into the shoes of one of your users and give your refactored workflow another go.

01:27 If you now submit a feedback form on the app’s main page, you are quickly redirected to the success page. You could even return to the feedback form and submit another response immediately.

01:40 But what happens in the backend with the synchronous example, you saw the email message appear in the terminal window where you ran Django’s development server, but this time it won’t show up there even after the 20 seconds have passed.

01:54 Instead, you’ll see that the email text appears in the terminal window where you’re running Celery alongside other logs about handling the task. Because you ran your Celery worker with log level info, you can read a verbose description of what’s happening on Celery’s end.

02:10 First, you may notice that the logs inform you about receiving send_feedback_email task. If you watch this terminal window right after submitting a feedback response, then you’ll see that this log line prints immediately after that Celery enters a waiting phase caused by the sleep call that previously froze the Django app.

02:30 While you can now continue using your Django app, Celery performs the expensive calculation for you in the background. After the 20 seconds have passed Celery prints the dummy email that Django builds with send_mail to the terminal window.

02:45 It then adds another log entry that tells you that the send_feedback_email task succeeded, and how long it took and what its return value was.

02:57 Keep in mind that your Django app won’t know whether or not the Celery task has succeeded. That means the thank you message your reader sees doesn’t necessarily mean that the message has made its way safely to you.

03:09 Because you set up a database backend with Redis, you could, however, query that backend to identify whether a task run was successful or not. Because of the way HTTP works, informing the user on the front end about whether a background task is finished successfully is not a trivial task.

03:27 To accomplish this, you’ll need to set up Ajax polling or web sockets via Django channels. And if you want to take this second route, Real Python has you covered.

03:39 Your feedback seems to have been submitted quickly, and you didn’t have to sit through a frustrating waiting time. You’ve successfully integrated Celery into your Django app and set it up to process.

03:49 An asynchronous task Celery now handles your email sending and all of its overhead as a background task. Email sending doesn’t need to concern your web app once it’s passed the task instructions to Celery’s distributed task queue.

04:05 In the next section of the course, you’ll take a look back at what you’ve learned.