Empty response in 30% of cases when reloading page in Angular app (Chrome, error code 14)

[homeboyworks]

Hello, guys. I've found a couple similar threads here and I would appreciate for any additional information. If one of them is the case, please let me know.

This: #564
and this: #152

Seems like the problem happens only in Chrome browser. It's weird. Sometimes problem happens 5-7 times in sequence, sometimes only one time after 8-10 successful tries.

We have:

Angular 7 Typescript app with grpc stuff from CommonJs on front-end and Envoy Golang backend. When it loads it makes request via grpc-web. Same endpoints are working with the mobile app as well. Unfortunately in web app when page loading the response object from grpc is null.

Here is implementation:

import * as users from '../../../../web-commonjs/users/users_pb.js';`
import { UserServiceClient } from '../../../../web-commonjs/users/users_grpc_web_pb.js';

const username = 'some_username';
const request = new users.GetPublicProfileRequest();
request.setUsername(username);

const userService = new UserServiceClient(environment.hostname, null, null);
const call = userService.getPublicProfile(request, null,
  (err: grpcWeb.Error, response: users.GetPublicProfileResponse) => {
    
    console.log('---------------  server GetPublicProfileResponse ---------------');
    console.log(response); // <----------- THIS IS NULL SOMETIMES
    
    if (response) {
      console.log('happiness');
    }
    
    if (err) {
      console.log('damn');
      console.log(err);
    }
  });

Error which is printed in browser console is vary:

• {code: 14, message: "Http response at 400 or 500 level"}
• {code: 14, message: "upstream connect error or disconnect/reset before headers. reset reason: connection termination"}

P.S. You've mentioned that typescript option is experimental and you would like to get a feedback. I've tried typescript and commonjs+dts. I am afraid in our case some of declaration methods were not matching the source files. Some mess in names of functions. It can be a mistake on preparing the sources on backend, I'm not sure. So that's why commonJs looks like a clear solution for our small app.

[Plotist]

@homeboyworks I think #564 has nothing to do with it - the issue there was that because of incorrect hostname for Enovy configuration inside docker container backend and frontend were not connected at all.

As per your issue: Have you tried bumping up connect_timeout for your backend cluster?
(See envoyproxy/envoy#3492 (comment), envoyproxy/envoy#815)

[homeboyworks]

@Plotist Thanks you! Your advise helped us. We've changed it from 0.25s to 5s and that was the problem solving. Cheers!