GRPC assertion failure when subscribing to streams
See original GitHub issueNot exactly sure what is causing this error, it seems to be pretty sporadic and only happen after running a few iterations of testing.
Assertion failed: stream->dep_prev (../deps/nghttp2/lib/nghttp2_stream.c: nghttp2_stream_dep_remove: 777)
It seems that this test is able to reproduce it most of the time with the added loop:
describe('Eventstore GRPC Client', () => {
let client: EventStoreDBClient
beforeAll(() => {
client = new EventStoreDBClient(
{
endpoint: {
address: process.env.ES_HOSTNAME ?? 'eventstore',
port: parseInt(process.env.ES_GRPC_PORT ?? '2113'),
},
},
{ insecure: true },
{
username: process.env.ES_USERNAME!,
password: process.env.ES_PASSWORD!,
},
)
})
it('can subscribe to a stream', async () => {
jest.setTimeout(10000)
for (let j = 0; j < 10; ++j) {
const stream = `test_${uuidv4().replace(/\-/g, '')}`
const events = []
for (let i = 0; i < 10; ++i) {
events.push(
jsonEvent({
type: 'test-event',
id: uuidv4(),
data: {
a: i,
},
}),
)
}
const appendRes = await client.appendToStream(stream, events.slice(0, 3), {
expectedRevision: NO_STREAM,
})
const received: ResolvedEvent[] = []
const sub = client.subscribeToStream(stream, {
fromRevision: START,
})
sub.on('error', (err) => console.log(err, err?.message))
sub.on('close', () => console.log('subscription stopped'))
sub.on('data', (evt) => {
console.log(`received event ${events.length}`)
received.push(evt)
})
while (received.length < 3) await forMs(10)
await client.appendToStream(stream, events.slice(3, 10), {
expectedRevision: appendRes.nextExpectedRevision,
})
while (received.length < 10) await forMs(10)
expect(received.map((e) => e.event?.id)).toStrictEqual(events.map((e) => e.id))
await sub.unsubscribe()
}
})
})
This is my eventstore configuration (from docker compose) for testing
eventstore:
image: eventstore/eventstore:20.10.0-bionic
environment:
EVENTSTORE_START_STANDARD_PROJECTIONS: 'true'
EVENTSTORE_INSECURE: 'true'
EVENTSTORE_RUN_PROJECTIONS: 'All'
This was tested with Alpha 13.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
AssertionError: Assertion failed with Envoy and GRPC ...
Method without stream like getTime() which returning int64 works fine, i can parse response. But every method using streamed object like stream ......
Read more >gRPC Async Server : send stream from client ... - Stack Overflow
Here it's my GreeterAsyncServer. The assertion failed is at line GPR_ASSERT(ok); : ok is false when client sends colors (string) void ...
Read more >[grpc-core] assertion failed: cq_event_queue_num_items(&cc ...
1. I am using bidirectional async stream to maintain the heartbeat between server and client. 2. The assertion is in client side exiting...
Read more >grpc/grpc - Gitter
Hello! I'm using GRPC inside GKE, between 2 GKE services. I use bi-directional streaming service, which is not idle (at least each one...
Read more >gRPC Python 1.46.2 documentation
Creates an RpcMethodHandler for a unary-stream RPC method. Parameters ... The channel has seen a failure from which it expects to recover. SHUTDOWN¶....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi guys,
Thanks for the further details. Turns out I needed to increase the number of loops to see the error, though it seems to only happen occasionally, so may have just been increasing the chances of me hitting it.
The cause of the error looks to be https://github.com/grpc/grpc-node/issues/1652, that (one more issue down the chain), points towards it being caused by a bug in node itself.
In #129, I’ve added your reproduction as a test case and applied the workaround provided in the issue.
Awesome, thanks for the quick turnaround!