Same thing happened here:

https://uberchromegw.corp.google.com/i/chromeos/builders/wizpig-release/builds/729

https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/93996951-chromeos-test/

maybe some GS downtime?

Didn't get a chance to look into this bug. @deputies, please find a owner for the test log uploading problem. 

https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/93992696-chromeos-test/

It's loaded for me. Some time, there is a delay on the log upload. cautotest should redirect you to shard to list logs not uploaded yet. However, some time apache runs in to some issue and failed to response, that's why it redirected you to an empty GS page.

Do you really think this should not be fixed?

I am running into this a lot.  Are you saying that there is no way to return an error, instead of reporting "there are no objects in this folder"?  It makes a big difference to know that the logs will be uploaded later, rather than just thinking "oh drats another infra bug" and never checking again.

It would help to just leave an initial file in the bucket with some information about when to expect the logs to arrive.

This is related to the whole log collection work flow. In some case, like CQ runs, logs for passed test won't even being uploaded to GS. They will be kept on drone/shard for 24 hours and then deleted.

"leave an initial file in the bucket"
That requires test to have up front knowledge of what and where to upload, not likely going to work with the current flow.

The root cause of this issue is that apache becomes unresponsive on shard/drone. We have nagios alerts on apache. Whenever I received that alert, I will do a service apache2 reload to fix that problem. Ideally we can automate that (require bunch of permission hack for nagios user to reload apache), also, we don't understand why apache becomes unresponsive on the first place, which may deserve more investigation.

Oh wait I think I understand now.

The message "there are no objects in this folder" leaves the impression that there is an empty folder.  But the truth is that there is no folder.

Try with an impossible URL:

https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/1234567890123456789012345678901234567890-chromeos-test/

Result:

"There are no objects in this folder"

So that's where the bug is.  The message should either say

"This folder does not exist"

or, if the semantics of GS make it impossible to distinguish between an empty folder and a non-existing folder, the error should say so:

"This folder does not exist or it is empty"

or, if there are no folders (i.e. directories in the traditional sense), the message should be

"There are no objects with this prefix"

(although this is unlikely to be the case, because of performance)

I would like to pass this along to GS, but if you have any input I'd love to hear it.

A better error message will certainly help. I just trained my brain to translate "no objects in this folder" to results not available on GS..

I have had a discussion on g/cloud-storage-discuss and g/gcs-hotline about this.  As a result, they opened b/34388551.  So we're done here---we can close it after that bug is closed.

Bulk closing Infra>Client>ChromeOS issues untouched in over a year.