Job Batching Progress with Laravel
This episode is for members only

Sign up to access "Job Batching Progress with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
12. Clearing up after the batch finishes

Episodes

0%
Your progress
  • Total: 1h 37m
  • Played: 0m
  • Remaining: 1h 37m
Join or sign in to track your progress

Transcript

00:00
OK, let's do a little bit of tidying up once our full batch successfully completes. First of all, we're going to head over to where we failed this and just get rid of the exception that we're throwing. We want the entire batch to run through.
00:13
And again, we have another callback here, which is then. So this is when everything in the job chain or batch has finished processing. OK, so once again, we get the batch in here if we need it. And what do we want to do in this instance?
00:27
Well, we want to go ahead and just update the server with a couple of additional details, like when it was provisioned. And we want to clear up all the existing tasks that we have. So let's go ahead and do this now.
00:38
And then I'm just going to talk to you about how our batch within our queue actually knows what this server is. We'll dive into the database a bit deeper. OK, so once everything has successfully, and this is really important, successfully
00:51
finished, we're going to update our server and we're going to set the batch ID to null. We don't really need that hanging around. We don't need to read any more information about this batch. So we can just get rid of that.
01:02
So the data isn't hanging around and we're going to go ahead and set the provisioned at date to the current date and time, and then we can go ahead and just delete all the tasks. The only purpose of these being in the database here is so we can keep track
01:15
of them when we're provisioning our server or when we're performing any other actions in this batch. So let's go ahead and say server tasks delete. And of course you can do absolutely anything in here that you need to do.
01:28
Okay. Let's see this action. So let's make sure that we are closing off and rerunning our queue. Let's go over to the database and just get rid of anything in here that we don't
01:36
need, including our job batch, and let's rerun this from the UI. Okay. So we're going to go over, we're going to wait for all of these tasks to run through. So again, we're going to have to wait like 15 seconds for each one of these to go
01:48
through, but once this has finished, we'll go over to our servers table and have a look at what we have in here. So let's just wait for this last one to finish. And once that is complete, sure enough, all of the server tasks have now been deleted.
02:02
If we head over to the server, the batch ID has been set to null and the provision.date has been set to the current date and time when this finished. Okay. So the question now, just to dive a little bit more deeply into this is how does this
02:15
know inside of our queue when we're technically not running this entire thing within one session, know how to access the server. Let's just dive in and see what we have within our job batches. So if we look in here, we've actually got a serialized options field in here.
02:32
Let's just copy everything inside of there, head over and just pull up a new plain text scratch file. What you'll notice is all of the data that we are using within this batch. So everything within that observer is being serialized in here.
02:46
Let's just look for where we are progressing this. So let's search for our progress callback here. You can see that it's basically just listing out all of the code we wrote inside of that batch.
02:57
Now it knows what this server is because that data has been serialized here. So you can see that the model here is the server model and it contains the ID. So every time this is getting run in our queue in the background, we get an ID out, which tells Laravel what it needs to refetch from the database in
03:16
order to do all of these things. So let's go back over to the database and just check out that server. And sure enough, we can see if we pull that out, that has a server ID of 30. So all of this is getting serialized.
03:28
And that means that Laravel can extract all of this model data out to go ahead and perform an action for each progress or when this fails, anything that we're currently doing inside of our code. So that's just how that works in the backend.
03:42
If you have any problems with rehydrating data inside of any of these callbacks, it's likely to do with how this has been serialized. You won't often find problems with this, but if you do see any issues, the serialized data is the place to look to figure out if anything has gone wrong.

Episode summary

In this episode, we're cleaning up after a batch operation in our Laravel queue finishes successfully. We start by removing the custom exception we used to simulate a failure before, making sure our whole batch runs through from start to finish.

Next, we take advantage of the then callback, which fires once everything in the batch/process chain has wrapped up. In this section, we update our server to set the provisioned_at datetime, clear out any existing tasks related to the batch, and set the batch_id to null—basically making sure there's no leftover data we don't need anymore.

We step through these changes in the database, watching the queued jobs finish, and then check that our tasks were deleted and our server was updated as expected. From there, we dig into how Laravel keeps track of which server we're working with: by storing a serialized version of the relevant data (including the model and its ID) within the job batch's options.

Finally, we do a little debugging to show how you can inspect this serialization if you ever run into issues with rehydrating data in callbacks. If things go wrong, this is usually the first spot to check.

All in all, this episode is all about best practices for cleaning up after your batches and understanding how Laravel manages data across asynchronous jobs.

Episode discussion

No comments, yet. Be the first!