Callback-based remote method in mounted LB3 app causes error when connection is prematurely terminated

Discussed in https://github.com/loopbackio/loopback-next/discussions/7196

^{Originally posted by rmsgit January 5, 2021}
Hi all, I'm trying to mount loopback 3 app into loopback 4 app. Currently, I successfully mounted according to the official documentation. But when I trying to do a load test (virtual users: 300 / sec, timeout: 10s), "ERR_HTTP_HEADERS_SENT" error is throwing. When I trying with lb3 or lb4 individually it's never happening for this load. Additionally, when I increase timeout duration in load test, the rate of error accruing is decreasing.

(node:10426) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 117)
2021-01-05T07:23:07.000Z - info: IP: ::ffff:127.0.0.1, CustomerId: XXXXXXXXXXXXXXXX, login. User
(node:10426) UnhandledPromiseRejectionWarning: Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
at ServerResponse.setHeader (_http_outgoing.js:526:11)
at ServerResponse.header (<project_path>/node_modules/express/lib/response.js:771:10)
at ServerResponse.json (<project_path>/node_modules/express/lib/response.js:264:10)
at <project_path>/lb3app/server/boot/user.js:47:8
at tokenHandler (<project_path>/node_modules/loopback/common/models/user.js:287:9)
at <project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/relation-definition.js:1919:13
at <project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/dao.js:427:21
at doNotify (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)
at doNotify (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)
at doNotify (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)
at doNotify (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)
at Function.ObserverMixin._notifyBaseObservers (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:178:5)
at Function.ObserverMixin.notifyObserversOf (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)
at Function.ObserverMixin._notifyBaseObservers (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)
at Function.ObserverMixin.notifyObserversOf (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)
at Function.ObserverMixin._notifyBaseObservers (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)
at Function.ObserverMixin.notifyObserversOf (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)
at Function.ObserverMixin._notifyBaseObservers (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)
at Function.ObserverMixin.notifyObserversOf (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)
at AccessToken. (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/dao.js:426:25)
at AccessToken.next (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/hooks.js:93:12)
at AccessToken. (<project_path>/node_modules/loopback/node_modules/loopback-datasource-juggler/lib/dao.js:414:26)

Inizia dalla discussione 7196 e dallo stack trace riportato, in particolare lb3app/server/boot/user.js:47 e dalla configurazione montata di LoopBack 3/4. Riproduci il carico di 300 utenti al secondo con un timeout di 10 secondi e determina cosa succede quando la connessione termina prematuramente; il lavoro è completato quando la richiesta non produce più ERR_HTTP_HEADERS_SENT né una unhandled rejection.