When Archived Results aren't available for a particular flood after a test, it's usually because the underlying grid was stopped before it could transfer results to Flood. If you are running a grid on our demand infrastructure, this won't happen to you (unless you're stopping grids manually)-- we automatically stop grids after the files have finished being transferred. However, if you are hosting your own infrastructure and controlling the grid duration, you may be ending the grid too early.
On Flood, the grid duration time gives precedence over any test duration set. This is because you are paying for grid time, not the time a test takes to complete. If we didn't have this rule, we could potentially be running up massive charges for a test that was stuck in an infinite loop due to a scripting mistake.
When you stop a grid or its duration runs out, we begin to immediately shut down the virtual machine(s). If a flood is still running when a grid shuts down, there may not be enough time for the results to be copied to Flood, resulting in data loss.
To prevent this from happening, allow some time after a flood before you stop the grid. If you're monitoring the test, you can wait until the flood's status changes to "Completed" (the check mark), and then it should be safe to stop the grid.
If you're not monitoring your test, the time it takes for results to transfer may vary depending on how long the test was and whether you're logging anything else in your test script. We recommend you monitor the test a few times to get a feel for how long it usually takes, and then planning accordingly when you're scheduling an unmanned test.
Once a grid node shuts down, all the data on it is deleted. Unfortunately, if the archived results aren't saved due to inadequate time for shutdown related processes (i.e. saving these archives to s3 storage) then there's not much we can do about restoring these archives.