Does the user also experience the problem when http/2 is disabled (Launch Chrome with the '--disable-http2' flag)? It also looks like ServiceWorker is involved with this request.

@svaldez I'll ask them to try with http2 disabled, it's their home computer so it might be end of day before they get back to me.

Both 192162 and 192174 don't have any information. How can you know that these are the problematic requests?

> - The request is a POST request to our backend
> - The request is never reaching our backend (according to our logs)

Can you tell me the URL of "the request"?

@yhriano

I think those are the problematic requests based on:
1. Their adjacency to related requests (doing the same action on my machine, the sign_in request is in the same area).
2. The fact that his console shows the sign_in request failing and then not finding it within the network requests.

IS it common for network requests to not have information?

The url is "https://mail.superhuman.com/~backend/auth/sign_in?idToken=..."

Also, more news! He tried to sign in with http2 disabled, and it looks like there's more information on the request: `--> delegate_blocked_by = "RedirectToFileResourceHandler"`. See 1155 in the attached net internals log.

Forgot to attach it :)

Deleted: net-internals-log (3) (1).json 243 KB

net-internals-log (3) (1).json 243 KB View Download

1155: URL_REQUEST
https://mail.superhuman.com/~backend/auth/sign_in?idToken=...
Start Time: 2017-04-06 22:52:09.028

t=1404 [st=   0] +REQUEST_ALIVE  [dt=5084]
                  --> priority = "MEDIUM"
                  --> url = "https://mail.superhuman.com/~backend/auth/sign_in?idToken=..."
t=1404 [st=   0]   +DELEGATE_INFO  [dt=5084]
                    --> delegate_blocked_by = "RedirectToFileResourceHandler"
t=6488 [st=5084]      CANCELLED
                      --> net_error = -2 (ERR_FAILED)
t=6488 [st=5084] -REQUEST_ALIVE

dmurph@, is it the same issue as issue 673478?

yhirano@, it seems I don't have permission to view 673478, can you tell me what it pertains to (or give me permission)?

If there's something we can change in the network request to resolve this, I'd be happy to deploy and see if it fixes it.

Yes. And it looks like it doesn't have anything to do with blobs.

> islam@

Do you know how the request to the url ("https://mail.superhuman.com/~backend/auth/sign_in?idToken=...") is sent?
I think it is a XMLHttpRequest with "blob" responseType?
Is this correct?

If so, this issue may be caused by a full disk error.

yes - actually if cccleaner fixed it, I'm guessing the temp directory is full. The blobs urls are NOT released by this website, so I'm 90% sure that this is happening. One solution will be to move the blobs here to the user directory / partition and add them to the blob quota for files. This will still result in the same issue if the blobs urls are not released.

We are using an xhr with responseType of blob. I'll push a change to responseType in the next few days and find out if it resolves the issue for our user.

Thank you for providing more feedback. Adding requester "horo@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Also, sorry, I mixed up bugs here. Questions here are:

Do you create URLs from these blobs?
Do you release these urls?
Do you keep these blobs around?
Can you have the user experiencing save their about://blob-internals page? Looking for anything that has a status of ERR_*


The blob responseType saves a file to the user's disk, so yes if it's a full disk then it won't work.

The blobs from XHR are created for a fetch polyfill. We create a Response object from the blobs and typically we call `response.json()` sometime later.

In two cases the responses have `response.blob()` called and an object url is created.
In those two cases we do call `revokeObjectURL`, but might be leaking some.

Finally, in a chrome extension we also get blobs from CacheStorage and call `createObjectURL` without revoking it.

The blobs from the XHR are not used beyond that.

I'll ask the user about the about://blob-internals page.

Thank you!

Attaching the content of blob-internals -- doesn't look like there's anything with an error status...

Deleted: blob.txt 1.6 KB

blob.txt 1.6 KB View Download

Do you know if those users have a full, or nearly full, harddisk?

Hi, I'm the user. No, my disks are pretty free.

Deleted: Capture.PNG 9.9 KB

	Capture.PNG 9.9 KB View Download

Hm... so based on the info here, it looks like since the request asks for a blob, we have a RedirectToFile handler. And you're saying that the request never hits the server, so for some reason that handler is failing the request early.

This points to something being weird in the network stack maybe?

dmurph: Can you please route this to the right folks?

This is a network stack issue. Removing myself as owner.

Scoping down to one specific component to avoid falling into the trap of responsibility diffusion. #22 hints at Internals>network.

Please bounce back if the component is incorrect.

Given that ccleaner fixes it, a full temp directory seems likely to be the culprit. Is there anything we can do about this?

Blocked on moving the blob xhr storage directory to the new user partition directory we use for paging.

Moving out of the triager queue until the parent is resolved.

With servicification, this path is being completely rewritten.