Unhandled 'error' event crash #62

jmillan · 2018-04-24T10:42:33Z

Environment details

OS: Debian 8.10
Node.js version: v8.10.0
npm version: 5.6.0
@google-cloud/speech version: 1.4.0

Target

Get continuous transcriptions from an audio stream which length is undefined.

NOTE: I am aware of the quotas and limits for the speech recognition service.

Observations

As shown in the shared code, the streamingRecognize() write steam is re-generated on every data event which reports an error (typically being: exceeded maximum allowed stream duration of 65 seconds).

After some time (usually less than 5 minutes) the following unhandled exception is thrown which stops the application completely:

events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: 14 UNAVAILABLE: 502:Bad Gateway
    at createStatusError (/service/node_modules/grpc/src/client.js:64:15)
    at ClientDuplexStream._emitStatusIfDone (/service/node_modules/grpc/src/client.js:270:19)
    at ClientDuplexStream._receiveStatus (/service/node_modules/grpc/src/client.js:248:8)
    at /service/node_modules/grpc/src/client.js:804:12

The logs clearly point to grpc.

Questions/Concerns

My main question is: Is it actually possible to achieve continuous transcriptions of undefined audio lengths by using StreamingRecognize or any other ways provided by this service?

If there is a way to achieve this with StreamingRecognize.How can the exposed error be avoided, or achieved in any other way?

Thanks.

Code that reproduces the crash

const speech = require('@google-cloud/speech');

class GoogleSpeech
{
	constructor({ languageCode = 'en-US' })
	{
		logger.debug('constructor()');

		// Google Speech client.
		this._client = new speech.SpeechClient();

		// Google Speech configuration request.
		this._request =
		{
			config : {
				encoding              : 'LINEAR16',
				sampleRateHertz       : 16000,
				enableWordTimeOffsets : true,
				languageCode
			},
			// 'true' to perform continuous recognition even if the user pauses speaking.
			singleUtterance : false,
			// 'true' to enable tentative hypoteses.
			interimResults  : true
		};

		// Plain audio readable stream.
		this._audioStream = null;
	}

	/**
	 * @param {Readable} audioStream
	 */
	start(audioStream)
	{
		logger.debug('start()');

		this._audioStream = audioStream;

		this._start();
	}

	stop()
	{
		logger.debug('stop()');
	}

	_start()
	{
		logger.debug('_start()');

		try
		{
			// Create a writable stream to which pipe the plain audio.
			this._recognizeStream = this._client.streamingRecognize(this._request);
		}
		catch (error)
		{
			logger.error('streamingRecognize() error: [%s]', error.message);

			return;
		}

		this._recognizeStream
			.on('error', (error) =>
			{
				logger.error('streamingRecognize() "error" event [%s]', error.message);
				this._audioStream.unpipe(this._recognizeStream);
			})
			.on('data', (data) =>
			{
				if (data.error)
					logger.error('streamingRecognize() "data" event error [%s]', data.error);

				else
					logger.debug(data.results[0].alternatives[0].transcript);
			})
			.on('unpipe', () =>
			{
				delete this._recognizeStream;

				this._start();
			});

		// Pipe the audio stream into the Speech API.
		this._audioStream.pipe(this._recognizeStream);
	}
}

The text was updated successfully, but these errors were encountered:

niravpatel2008 · 2018-04-24T10:53:09Z

Hi @jmillan

I was also facing this issue and cause of that my application get crashed.

I just get fixed in tricky way Create new recognition object after every 50 sec and unpipe previous one
And use try cache while creating new object of recognition and in cache recall init method like below code.

var recognizeStream;
var initSpeechToText = function(){
		try
		{
			return self.speech_to_text.streamingRecognize(self.recognizeStreamOpt)
				.on('error', (e)=>onError)
				.on('data', data => onData)	
		}
		catch (e)
		{
			console.log("ERROR BIG", e);
			return initSpeechToText();
		}
}

var startStt = function(flag){
	if (flag)
	{
		bufferStream.unpipe(recognizeStream);
		console.log("re init after 60 sec");
	}
	
	recognizeStream = initSpeechToText();
	bufferStream.pipe(recognizeStream);
}

startStt();
sstInterval = setInterval(() => { startStt(true) } , 60000);

will fix bad gateway 502 error.

jmillan · 2018-04-24T11:08:21Z

Hi @niravpatel2008,

I just get fixed in tricky way Create new recolonization object after every 50 sec

I guess you mean recognition when saying recolonization. Do you refer to the write stream returned by streamingRecognize()?

and unpipe previous one will fix bad gateway 502 error.

Let me try to understand what you say. Lets consider that we already have a read stream piped to a write steam and we are getting the transcripts:

Create new write stream out of streamingRecognize()
Unpipe read stream from current write stream.
Once unpiped, pipe read stream with new write stream, which is from now on the current one.
Wait 50 seconds
Goto 1

niravpatel2008 · 2018-04-24T11:34:14Z

@jmillan

Sorry its my mistake due to auto correct(its recognition not recolonization).

Yes you are on right track please implement your steps and hope it will also works for you.

jmillan · 2018-04-24T11:49:15Z

Already testing,

Thanks for you comments @niravpatel2008

niravpatel2008 · 2018-04-24T12:09:45Z

@jmillan

Please have look at update comment

jmillan · 2018-04-24T12:46:25Z

Sill experiencing the crash within this code:

	_start()
	{
		logger.debug('_start()');

		this._recognizeStream = this._createRecognizeStream();

		// Pipe the audio stream into the Speech API.
		this._audioStream.pipe(this._recognizeStream);

		// Substitute current recognizeStream with a new one before timeout expiration.
		setTimeout(() =>
		{
			this._audioStream.unpipe(this._recognizeStream);
		}, 50 * 1000);
	}

	_createRecognizeStream()
	{
		logger.debug('_createRecognizeStream()');

		const recognizeStream = this._client.streamingRecognize(this._request);

		recognizeStream
			.on('error', (error) =>
			{
				logger.error('streamingRecognize() "error" event [%s]', error.message);
			})
			.on('data', (data) =>
			{
				if (data.error)
					logger.error('streamingRecognize() "data" event error [%s]', data.error);

				else
					logger.error(data.results[0].alternatives[0].transcript);
			})
			.on('unpipe', () =>
			{
				logger.debug('unpiped, ending old recognizeStream');

				recognizeStream.end();

				this._start();
			});

		return recognizeStream;
	}

After some time:

events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: 14 UNAVAILABLE: 502:Bad Gateway
    at createStatusError (/service/node_modules/grpc/src/client.js:64:15)
    at ClientDuplexStream._emitStatusIfDone (/service/node_modules/grpc/src/client.js:270:19)
    at ClientDuplexStream._receiveStatus (/service/node_modules/grpc/src/client.js:248:8)
    at /service/node_modules/grpc/src/client.js:804:12

jmillan · 2018-04-24T12:57:40Z

Please have look at update comment

I just have seen this comment. Checking right now.

jmillan · 2018-04-24T13:28:59Z

Not even with the minimum code possible

	_start()
	{
		logger.debug('_start()');

		this._recognizeStream = this._createRecognizeStream();

		// Pipe the audio stream into the Speech API.
		this._audioStream.pipe(this._recognizeStream);

		// Substitute current recognizeStream with a new one before timeout expiration.
		setTimeout(() =>
		{
			this._audioStream.unpipe(this._recognizeStream);

			this._start();
		}, 60 * 1000);
	}

	_createRecognizeStream()
	{
		logger.debug('_createRecognizeStream()');

		const recognizeStream = this._client.streamingRecognize(this._request);

		recognizeStream
			.on('error', (error) =>
			{
				logger.error('streamingRecognize() "error" event [%s]', error.message);
			})
			.on('data', (data) =>
			{
				if (data.error)
					logger.error('streamingRecognize() "data" event error [%s]', data.error);

				else
					logger.error(data.results[0].alternatives[0].transcript);
			});

		return recognizeStream;
	}

The issue must be somewhere else releated to grpc itself more than within the use of the speech library.

niravpatel2008 · 2018-04-24T13:36:02Z

@jmillan Please add try cache like below. 502 Bad Gateway is generic error code here is the link for [causes] (https://www.lifewire.com/502-bad-gateway-error-explained-2622939).

So just to fix this issue lets add try catch block in your code which will fix this issue. until grpc lib dev fix in library.

_start()
{
	logger.debug('_start()');

	this._recognizeStream = this._createRecognizeStream();

	// Pipe the audio stream into the Speech API.
	this._audioStream.pipe(this._recognizeStream);

	// Substitute current recognizeStream with a new one before timeout expiration.
	setTimeout(() =>
	{
		this._audioStream.unpipe(this._recognizeStream);

		this._start();
	}, 60 * 1000);
}

_createRecognizeStream()
{
	try
	{
		logger.debug('_createRecognizeStream()');
		
		const recognizeStream = this._client.streamingRecognize(this._request);

		recognizeStream
			.on('error', (error) =>
			{
				logger.error('streamingRecognize() "error" event [%s]', error.message);
			})
			.on('data', (data) =>
			{
				if (data.error)
					logger.error('streamingRecognize() "data" event error [%s]', data.error);

				else
					logger.error(data.results[0].alternatives[0].transcript);
			});

		return recognizeStream;
	}
	catch(e)
	{
		return this._createRecognizeStream();
	}
}

jmillan · 2018-04-24T13:42:14Z

I used to have try/catch there originally (before opening this issue) and I was getting the error. Anyway I've just put it and test is ongoing.

Thanks. Will update here.

jmillan · 2018-04-24T14:22:23Z

Exception happened again.

There's no alternative left but going down to grpc.

jmillan · 2018-04-24T15:34:01Z

In case this brings some light to someone who knows about grpc:

This is result of setting an uncaughtException event handler in the process:

  uncaughtException:  { Error: 14 UNAVAILABLE: 502:Bad Gateway
    at createStatusError (/service/node_modules/grpc/src/client.js:64:15)
    at ClientDuplexStream._emitStatusIfDone (/service/node_modules/grpc/src/client.js:270:19)
    at ClientDuplexStream._receiveStatus (/service/node_modules/grpc/src/client.js:248:8)
    at /service/node_modules/grpc/src/client.js:804:12
  code: 14,
  metadata:
   Metadata {
     _internal_repr: { 'content-length': [Array], date: [Array], 'alt-svc': [Array] } },
  details: '502:Bad Gateway' } +680ms

  uncaughtException metadata:  Metadata {
  _internal_repr:
   { 'content-length': [ '0' ],
     date: [ 'Tue, 24 Apr 2018 15:29:41 GMT' ],
     'alt-svc':
      [ 'hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"' ] } } +15ms

jmillan · 2018-04-24T16:29:39Z

Reproducible

The 5th time it creates a new write stream via streamingRecognize() it crashes.

niravpatel2008 · 2018-04-25T04:18:38Z

@jmillan i was also facing this issue but by changing in flow as i mentioned above try catch block and timer it fixed for me least its working for me.

marcelgoya · 2018-04-25T12:29:42Z

@niravpatel2008 I've just tried your try/catch fix and it also didn't work for me.

marcelgoya · 2018-04-25T12:56:39Z

For the folks from Google, is there any way to catch this exception or does it need to be fixed inside the library?

jmillan · 2018-04-26T14:48:15Z

The limits docs clearly state that there is a maximum streaming request time of 5 minutes, and that requests and/or attempts at audio processing in excess of these limits will produce an error.

Could anyone please confirm that what we are trying to achieve is currently not doable with google-speech?

jmillan · 2018-04-26T18:31:52Z

niravpatel2008, could you please share some details of your installation?

OS
Node.js version
npm version
@google-cloud/speech version
Parameters provided to streamRecognize()
Audio input type

Thanks in advance.

niravpatel2008 · 2018-04-27T04:33:06Z

@jmillan Sure below are the installation details.

OS : centos 6.5
Node.js version : v6.12.0
npm version: 5.5.1
@google-cloud/speech version : ^1.1.0
Parameters provided to streamRecognize() :

{
			config: {
			  encoding: "LINEAR16",
			  sampleRateHertz: "16000",
			  languageCode: "en-US",
			  profanity_filter: true,
			  model: "phone_call"
			},
			interimResults: true,
		}

Audio input type: wav (16k rate)

jmillan · 2018-04-27T05:25:45Z

Thanks @niravpatel2008,

How large is the wav file? Does it exceed 5 or even 10 minutes?

niravpatel2008 · 2018-04-27T05:51:56Z

@jmillan i am using wav streaming speech to text. and it wont be predefined but we have tested up to 20 mins of live streaming.

jmillan · 2018-04-29T06:15:23Z

Same scenario right now the problem is not reproduced...

jmillan · 2018-04-29T06:29:25Z

Ended up crashing again

phsultan · 2018-04-29T17:01:43Z

Hi José Luis,

You may want to give a try to a nodejs-speech wrapper I wrote for the same purpose, that is, get a continuous transcription for an audio file which size is not known in advance: https://github.com/phsultan/real-time-audio-transcription

It is currently limited to handling .wav files, as the sampling frequency is actually taken from the .wav header but that can be modified in the future to process raw audio samples. Basically, we aim to take recorded tracks from VoIP servers like Asterisk and FreeSWITCH and process them in real time by sending (synchronized only) transcription requests over the nodejs-speech NPM package.

I'd love to get your feedback for improvements if you find any interest in that program and have some time to try it out, thanks !

jmillan · 2018-04-29T18:59:58Z

Hi @phsultan,

You are not using streamingRecognize() as I do but embedding the audio in each request. I think our scenarios are not the same.

niravpatel2008 · 2018-04-30T04:09:30Z

@jmillan lets do one thing have one complete example which crashes for you and provide here. so i can download and test in my machine.

jmillan · 2018-04-30T17:39:14Z

Hi @niravpatel2008, the code is the one I've already exposed in this issue. It's a copy-paste literally.

manwe · 2018-05-01T09:29:27Z

Same problem here. I used similar code as I also want realtime transcription of audio streams during a telephony call.

phsultan · 2018-05-01T22:30:39Z

It looks like the reading pace for the Readable Stream attached to the audio needs to be controlled not to pipe audio data too fast, at least from my various tests.

To do so, I set the highWaterMark option on the Readable Stream and use setTimeout in the data listener like so:

let readStream = fs.createReadStream(filename, { highWaterMark: sampleRateHertz*2*0.2 });
  readStream.on('data', (chunk) => {
    readStream.pause();
    setTimeout(() => {
      readStream.resume();
    }, 200);
  })

This would simply read audio data every 200 msec (arbitrarly set and can be obviously changed).

Using this gist on a wav file of unknown size worked in my case (up ti 10 minutes of audio were tested). Be careful not to provide a 2 channels (stereo) file, and adjust the sampling frequency if needed (and the language of course :-)):

node streamingRecognize.js audio.wav --sampleRateHertz=8000 --languageCode=fr-FR

Based on the snippets provided by @jmillan and @niravpatel2008 , I added another gist that tries to match with you guys code but does what's described above.

All my testing have been done on LINEAR16, mono, and 8000Hz as sampling frequency, so make sure to adjust this value.

manwe · 2018-05-02T06:41:57Z

@phsultan during my tests, when you try to pipe audio too fast while using streamrecognize, you get a message about sending audio in realtime.
My readstream is a live audio recording that it's being generated in realtime. Can't send audio faster than it's being recorded. I send linear mono 8KHz.

stephenplusplus · 2018-07-24T18:36:56Z

Thanks. I believe my question from #62 (comment) is still accurate, then.

@JustinBeckwith / @kinwa91 could you forward this question to someone from the Speech team? Currently, it seems the behavior users are expecting is not possible.

jkwlui · 2018-08-02T17:47:16Z

Forwarded the issue with the Speech team - will update here when we know more!

jerjou · 2018-08-07T21:01:26Z

...man, javascript has changed a lot since I last touched it. Or maybe it's just that I can't read typescript.
¯\(ツ)/¯

Okay, so my first guess is that you're running into a grpc client deadline. ie the nodejs grpc client's makeBidiStreamRequest takes a client CallOptions object that has a deadline parameter. Presumably, this is the method that's being called behind the scenes by gax or something, but I don't know enough about it (and I can't seem to find it). Presumably that is set to a default value, which I also can't find, but it looks like you might be able to set it.

I'll keep digging, but you might try setting the timeout as mentioned above and see if that fixes it.

jmillan · 2018-08-14T08:12:00Z

Hi,

I'll work on providing you a reproducible environment so you can test and make sure the test is fixed.

jmillan · 2018-08-14T16:52:10Z

Hi,

Bug is reproducible now.

(node:6) DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead
streamingRecognize() "data" event error [code:11,message:Audio Timeout Error: Long duration elapsed without audio. Audio should be sent close to real time.]:

events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: 14 UNAVAILABLE: 408:Request Time-out
    at Object.exports.createStatusError (/service/node_modules/grpc/src/common.js:87:15)
    at ClientDuplexStream._emitStatusIfDone (/service/node_modules/grpc/src/client.js:235:26)
    at ClientDuplexStream._receiveStatus (/service/node_modules/grpc/src/client.js:213:8)
    at Object.onReceiveStatus (/service/node_modules/grpc/src/client_interceptors.js:1290:15)
    at InterceptingListener._callNext (/service/node_modules/grpc/src/client_interceptors.js:564:42)
    at InterceptingListener.onReceiveStatus (/service/node_modules/grpc/src/client_interceptors.js:614:8)
    at /service/node_modules/grpc/src/client_interceptors.js:1110:18

How get the test environment

git clone https://github.com/jmillan/NodeJsSpeechIssue62.git

Follow the instructions in the client and server folders.

Test environment description

The project has two parts: client and server.

Client

Takes your microphone as input audio if your platform is MacOS or Linux, otherwise it generates random audio. The audio is encoded into RTP and sent to the server.

Server

Runs in a Docker, hence you need to have it installed. Receives the RTP from the client, decodes it and passes the raw audio to Google speech.

How reproduce the crash

Run the client.
Run the server.
Kill the client (Ctrl-C)
Wait and check the server output. The crash will appear within a couple or three minutes.

ibc · 2018-08-14T17:01:56Z

@jerjou: Even if setting some parameter to certain value avoided the problem, the bug does exist. And the bug does exist because, somewhere, grpc-node library emits an "error" event that it not handled by gax or by nodejs-speech, and hence the Node process exists with error.

jerjou · 2018-08-14T21:54:23Z

This is a different thing - notice that the error message is different:

streamingRecognize() "data" event error [code:11,message:Audio Timeout Error: Long duration elapsed without audio. Audio should be sent close to real time.]:

This happens in the streaming api when I think 5 seconds elapses between audio data being sent to the API. Since it's a streaming API, the API expects audio data to be continuously sent (in near-realtime) until the client signals that it's done (via a halfclose on the underlying grpc connection. For python that corresponds to a StopIteration on the request stream. Not sure for nodejs), and if there's too long a delay between audio chunks being sent, you get this error.

I believe the original error from this bug was:

Error: 14 UNAVAILABLE: 502:Bad Gateway

Is that one reproducible?

ibc · 2018-08-14T22:11:24Z

@jerjou: nobody is telling that it should not fail. We just say that it should NOT crash the Node process. A library should never crash the whole Node process, but node-speech (or its dependencies gax or grpc-node) are crashing the Node process. Why?

Because, in some circumstances, nodejs-speech is emitting an "error" event that is not handled by any event listener (nor internally and neither possible to listen to it from the app given that no API is exposed for that). And it happens that, in Node, when an "error" event is emitted and there is no event listener for it, the whole Node process exits with error:

https://nodejs.org/api/events.html

This is the bug, and not whether the lib expects continuous audio stream or not. The app may do a "bad" usage of the library, but that should never imply a whole Node process crash.

Is that one reproducible?

Yes, just please check https://github.com/jmillan/NodeJsSpeechIssue62, an environment to reproduce the error.

jerjou · 2018-08-14T22:14:17Z

Ah - sounds like I'm not the appropriate person to address this, then. I'll jump off the thread and leave it to @stephenplusplus and @kinwa91 to provide error-handling hooks in the client lib.

ibc · 2018-08-14T22:16:06Z

Thanks

stephenplusplus · 2018-08-14T22:21:16Z

With the current example (https://github.com/jmillan/NodeJsSpeechIssue62), it's difficult to debug because:

It's trying to do something unsupported
It's a complex app to jump into

Could someone whip up a simpler reproduction case, or streamline the existing one?

ibc · 2018-08-14T22:34:18Z

Stephen, the issue is at JS level somewhere in nodejs-speech, gax or grpc-node. Some of them (probably the formers) are not setting a needed "error" event handler. If we remove nodejs-speech and gax, obviously there won't be any issue.

I cannot figure out any easier way to reproduce the problem. It crashes 100% of times when running the given steps.

jmillan · 2018-08-15T06:56:54Z

@stephenplusplus,

With the current example (https://github.com/jmillan/NodeJsSpeechIssue62), it's difficult to debug because:

It's trying to do something unsupported
It's a complex app to jump into

Give this a try: https://github.com/jmillan/NodeJsSpeechIssue62Simplified

0 depedencies, single file, no audio, crash 100% reproductivity.

stephenplusplus · 2018-08-29T20:17:40Z

Thank you, @jmillan! Fix sent in #156.

jmillan · 2018-08-29T21:09:01Z

Awesome :-)

timaschew · 2018-09-06T20:48:46Z

Will the MR also fix errors like this

events.js:165
      throw er; // Unhandled 'error' event
      ^

Error: 14 UNAVAILABLE: TCP Read failed
    at Object.exports.createStatusError (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/common.js:87:15)
    at ClientDuplexStream._emitStatusIfDone (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/client.js:235:26)
    at ClientDuplexStream._receiveStatus (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/client.js:213:8)
    at Object.onReceiveStatus (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/client_interceptors.js:1290:15)
    at InterceptingListener._callNext (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/client_interceptors.js:564:42)
    at InterceptingListener.onReceiveStatus (/Users/timaschew/dev/my-mirror/node_modules/grpc/src/client_interceptors.js:614:8)
    at /Users/timaschew/dev/my-mirror/node_modules/grpc/src/client_interceptors.js:1110:18
Emitted 'error' event at:
    at StreamProxy.Duplexify._destroy (/Users/timaschew/dev/my-mirror/node_modules/duplexify/index.js:191:15)
    at /Users/timaschew/dev/my-mirror/node_modules/duplexify/index.js:182:10
    at process._tickCallback (internal/process/next_tick.js:112:11)

sometimes the log contains this prefix error { streamingError

I'm using @google-cloud/speech@2.0.0

jmillan · 2018-09-13T09:26:07Z

Hi,

I'm about to test the fix.

The issue was opened for v1.4.0. The CHANGELOG.md file indicates that this has been fixed for v2.1.0.

I've updated to v2.1.0 and I'm getting the following error (error event in streamingRecognize() returned instance:

[3 INVALID_ARGUMENT: Malordered Data Received. Send exactly one config, followed by audio data.]

Would you be so kind to respond these questions,

How has the API changed for this error to happen?
Is v2.1.0 stable or beta?

In summary. I just would like to upgrade to the fixed version and make it work as before.

Thanks

fatihyasar · 2018-09-14T13:21:49Z

+1

stephenplusplus · 2018-09-14T15:00:09Z

Sorry for the trouble. I have a feeling that is a new issue, so I moved it over to here: #170

MallammaHR · 2018-11-06T06:05:48Z

RESTART: /home/pi/Desktop/mallu/python-sdk/examples/microphone-speech-to-text.py
Enter CTRL+C to end recording...
Error received: Handshake status 502 Bad Gateway
Connection closed
sir I am getting this error how to solv ethis problem .please can you help me..

stephenplusplus assigned jkwlui Jul 24, 2018

stephenplusplus mentioned this issue Aug 29, 2018

fix: Register error event handler immediately. #156

Merged

stephenplusplus closed this as completed in #156 Sep 11, 2018

ghost removed the priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. label Sep 11, 2018

JustinBeckwith reopened this Sep 14, 2018

JustinBeckwith added the triage me I really want to be triaged. label Sep 14, 2018

stephenplusplus mentioned this issue Sep 14, 2018

Malordered Data Received. Send exactly one config, followed by audio data. #170

Closed

stephenplusplus closed this as completed Sep 14, 2018

ubhatti mentioned this issue Dec 7, 2018

C++ continuous speech recognition GoogleCloudPlatform/cpp-samples#47

Closed

google-cloud-label-sync bot added the api: speech Issues related to the googleapis/nodejs-speech API. label Jan 31, 2020

Unhandled 'error' event crash #62

Unhandled 'error' event crash #62

Comments

jmillan commented Apr 24, 2018 • edited Loading

Environment details

Target

Observations

Questions/Concerns

Code that reproduces the crash

niravpatel2008 commented Apr 24, 2018 • edited Loading

jmillan commented Apr 24, 2018

niravpatel2008 commented Apr 24, 2018 • edited Loading

jmillan commented Apr 24, 2018

niravpatel2008 commented Apr 24, 2018

jmillan commented Apr 24, 2018

jmillan commented Apr 24, 2018

jmillan commented Apr 24, 2018

niravpatel2008 commented Apr 24, 2018 • edited Loading

jmillan commented Apr 24, 2018

jmillan commented Apr 24, 2018 • edited Loading

jmillan commented Apr 24, 2018

jmillan commented Apr 24, 2018

niravpatel2008 commented Apr 25, 2018

marcelgoya commented Apr 25, 2018 • edited Loading

marcelgoya commented Apr 25, 2018 • edited Loading

jmillan commented Apr 26, 2018 • edited Loading

jmillan commented Apr 26, 2018

niravpatel2008 commented Apr 27, 2018

jmillan commented Apr 27, 2018

niravpatel2008 commented Apr 27, 2018

jmillan commented Apr 29, 2018

jmillan commented Apr 29, 2018

phsultan commented Apr 29, 2018

jmillan commented Apr 29, 2018

niravpatel2008 commented Apr 30, 2018

jmillan commented Apr 30, 2018

manwe commented May 1, 2018

phsultan commented May 1, 2018

manwe commented May 2, 2018

stephenplusplus commented Jul 24, 2018

jkwlui commented Aug 2, 2018

jerjou commented Aug 7, 2018 • edited Loading

jmillan commented Aug 14, 2018

jmillan commented Aug 14, 2018

How get the test environment

Test environment description

Client

Server

How reproduce the crash

ibc commented Aug 14, 2018

jerjou commented Aug 14, 2018

ibc commented Aug 14, 2018 • edited Loading

jerjou commented Aug 14, 2018

ibc commented Aug 14, 2018

stephenplusplus commented Aug 14, 2018

ibc commented Aug 14, 2018

jmillan commented Aug 15, 2018

stephenplusplus commented Aug 29, 2018

jmillan commented Aug 29, 2018

timaschew commented Sep 6, 2018

jmillan commented Sep 13, 2018

fatihyasar commented Sep 14, 2018

stephenplusplus commented Sep 14, 2018

MallammaHR commented Nov 6, 2018

jmillan commented Apr 24, 2018 •

edited

Loading

niravpatel2008 commented Apr 24, 2018 •

edited

Loading

niravpatel2008 commented Apr 24, 2018 •

edited

Loading

niravpatel2008 commented Apr 24, 2018 •

edited

Loading

jmillan commented Apr 24, 2018 •

edited

Loading

marcelgoya commented Apr 25, 2018 •

edited

Loading

marcelgoya commented Apr 25, 2018 •

edited

Loading

jmillan commented Apr 26, 2018 •

edited

Loading

jerjou commented Aug 7, 2018 •

edited

Loading

ibc commented Aug 14, 2018 •

edited

Loading