There might be some merit to this, but it would be in exceptional cases only.
Basically, each image that is uploaded spawns an individual "archive" task in IA's queue. Those normally get picked up quite quickly, and they "snowball", meaning that the task that is executed looks ahead in the queue to find newer archive tasks to process as well. That snowballing stops when 1) no other archive tasks exist, 2) a limit of snowballed tasks has been reached (I think it's 50), or 3) when the lookahead hits a non-archive task (such as derive). Only after snowballing is done, a derive task is queued, so, as long as snowballing works properly, derives will always be queued after the images have all been imported.
However, this will not be the case when IA is doing the archive tasks quicker than you can upload the images. In that case, it will hit snowballing stop condition 1, and will queue up a derive at the end of the queue. If you're still uploading images at that time, the derive will have to run before the new images can be imported. Nonetheless, since archive tasks run at a much higher priority than most of the derive tasks, the derive will likely be "rushed", meaning that it is executed but forcefully interrupted momentarily after so that later non-derive tasks can be executed quicker. The later archive tasks will then queue up the new derive when done.
You can probably avoid having an early derive blocking up the queue for a while by indeed not queuing derives for images when uploaded, and only have the upload for the index.json queue the derive since that one always happens at the very end, as far as I know. But, in my opinion, because of rushing and snowballing, such cases would be rare enough that making such a change may cause more harm than good. Moreover, since deriving is vital to create the thumbnails, until a derive is done, the images will still display as "This image is not available yet" anyway. Finally, derives for CAA items often take less than a minute, so the delay shouldn't be too large either.
There might be some merit to this, but it would be in exceptional cases only.
Basically, each image that is uploaded spawns an individual "archive" task in IA's queue. Those normally get picked up quite quickly, and they "snowball", meaning that the task that is executed looks ahead in the queue to find newer archive tasks to process as well. That snowballing stops when 1) no other archive tasks exist, 2) a limit of snowballed tasks has been reached (I think it's 50), or 3) when the lookahead hits a non-archive task (such as derive). Only after snowballing is done, a derive task is queued, so, as long as snowballing works properly, derives will always be queued after the images have all been imported.
However, this will not be the case when IA is doing the archive tasks quicker than you can upload the images. In that case, it will hit snowballing stop condition 1, and will queue up a derive at the end of the queue. If you're still uploading images at that time, the derive will have to run before the new images can be imported. Nonetheless, since archive tasks run at a much higher priority than most of the derive tasks, the derive will likely be "rushed", meaning that it is executed but forcefully interrupted momentarily after so that later non-derive tasks can be executed quicker. The later archive tasks will then queue up the new derive when done.
You can probably avoid having an early derive blocking up the queue for a while by indeed not queuing derives for images when uploaded, and only have the upload for the index.json queue the derive since that one always happens at the very end, as far as I know. But, in my opinion, because of rushing and snowballing, such cases would be rare enough that making such a change may cause more harm than good. Moreover, since deriving is vital to create the thumbnails, until a derive is done, the images will still display as "This image is not available yet" anyway. Finally, derives for CAA items often take less than a minute, so the delay shouldn't be too large either.