-
DescriptionAfter migrating from Environment
1. Local / Single-node issue:
|
| Environment | No Credentials in Options | credentials: {} Workaround |
|---|---|---|
| Local (Mono-node) | ❌ TypeError (length of undefined) |
✅ Works |
| Production (Cloud) | ✅ Works | ❌ 16 UNAUTHENTICATED |
Our current implementation of publishToStream
/**
* Publish one or multiple events to the target stream.
*
* If the stream does not exist already, some custom retention policies
* may be added to the stream metadata.
*/
public async publishToStream(
streamName: string,
events: IKurrentEvent<any> | IKurrentEvent<any>[],
options?: AppendToStreamOptions,
) {
const jsonEvents: EventData<any>[] = this.normalizeEvents(events);
// FIXME: this is a workaround
// Force the non-batch append path in @kurrent/kurrentdb-client:
// The client chooses batchAppend whenever baseOptions.credentials is falsy
// and the server supports BatchAppend. Passing any truthy credentials value
// (we pass a benign empty object) forces the simple append path and avoids
// the protobuf oneof(deadline) bug observed in BatchAppend.
const nonBatchOptions: AppendToStreamOptions = {
...(options ?? {}),
// credentials: options?.credentials ?? ({} as any),
};
console.log(nonBatchOptions);
await this.kurrentClient
.appendToStream(streamName, jsonEvents, {
streamState: STREAM_EXISTS,
...nonBatchOptions,
})
.catch((error) => {
if (error instanceof WrongExpectedVersionError) {
return this.kurrentClient
.appendToStream(streamName, jsonEvents, nonBatchOptions)
.then(() => this.applyRetentionPolicyToStream(streamName));
} else if (
// since v6.0.0 CancelledError https://github.com/EventStore/EventStore-Client-NodeJS/releases/tag/v6.0.0
error instanceof UnavailableError ||
error instanceof CancelledError
) {
this.config.onAppendUnavailable();
}
throw error;
});
}Expected Behavior
The client should be able to determine the correct append path (Batch vs Simple) without requiring manual credentials overriding, and it should not crash with a TypeError when no credentials are provided in a local environment.
The stack trace suggests a potential issue within the google-protobuf serialization logic during a BatchAppend request, specifically when setting the deadline:
at proto.event_store.client.streams.BatchAppendReq.Options.setDeadline21100
Steps to reproduce
- Use
@kurrent/kurrentdb-clientv1.1.0. - Connect to a local single-node EventStoreDB.
- Call
appendToStreamwithout providingcredentialsin the call options. - Observe the
TypeErrorcoming fromgoogle-protobufviabatchAppend.ts.
Sorry this is a bit long, but I'd rather discuss it before figuring out if it's a library bug or if the bug is just me.
Beta Was this translation helpful? Give feedback.
Answered by
Venatum
Mar 20, 2026
Replies: 2 comments 6 replies
-
|
Thanks for the detailed issue. Just to confirm, are you running this on Node.js, or are you using a different runtime? Also, can you run the same code locally with the environment variable |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thank you for your response, and sorry for the oversight. We are running this on Node.js v24.11.1 I’ve also run the same code locally with
App logsEventStore logs |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
I couldn't reproduce this on my side. If you can make a minimal repro in a small repo, that would help boiling things down usually exposes the real problem. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback. I’ll do my best to put together a minimal reproduction as soon as possible (within a week), otherwise another member of the team will take over |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay, I can’t reproduce it on a new repo |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delayed follow-up, no one picked this up on our end during my absence... We've identified the root cause: it wasn't a bug in the client library itself. We had a shared internal library responsible for building and publishing events that was still depending on the old Once we aligned both the shared library and the application on Thanks again for the quick response and for asking the right questions. Closing this out. |
Beta Was this translation helpful? Give feedback.
Answer selected by
Venatum
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry for the delayed follow-up, no one picked this up on our end during my absence...
We've identified the root cause: it wasn't a bug in the client library itself. We had a shared internal library responsible for building and publishing events that was still depending on the old
@eventstore/db-clientpackage, while the application itself had already been migrated to@kurrent/kurrentdb-client. Because the two packages were coexisting in the dependency tree, the app was able to publish and read events through the Kurrent client just fine, but failed to do so through the EventStore one, which explained the inconsistent behavior we observed across environments.Once we aligned both the shar…