Can't connect by Deno

[pamoller]

I tried this programm with Node and weaviate-client 3.5.2

import weaviate from 'weaviate-client';

async function connectToLocalWeaviate() {
  const client = await weaviate.connectToLocal();
  console.log("hello");
}

connectToLocalWeaviate();

and it succeeds like:

$ node test.js
hello

I tried the similar programm with Deno (adding npm:-specifier)

import weaviate from 'npm:weaviate-client';

async function connectToLocalWeaviate() {
  const client = await weaviate.connectToLocal();
  console.log("hello");
}

connectToLocalWeaviate();

and It fails with:

$ deno run --allow-all test.js
error: Uncaught (in promise) WeaviateStartUpError: Weaviate startup failed with message: Weaviate failed to startup with message: Weaviate makes use of a high-speed gRPC API as well as a REST API.
      Unfortunately, the gRPC health check against Weaviate could not be completed.

      This error could be due to one of several reasons:
        - The gRPC traffic at the specified port is blocked by a firewall.
        - gRPC is not enabled or incorrectly configured on the server or the client.
            - Please check that the server address and port: localhost:50051 are correct.
        - your connection is unstable or has a high latency. In this case you can:
            - increase init-timeout in weaviate.connectToLocal({timeout: {init: X}})'
            - disable startup checks by connecting using 'skipInitChecks=true'

Any idea? Is it a Deno problem? Both ports (8080 and 50051) are port forwarded from a kubernetes cluster.

[DevChanQ]

Facing the same issue here on Deno

[ben-laird]

I have the same problem in v3.7.0 using Deno

[malgamves]

Hey @pamoller could you share with me what version of Deno you're running on?

[tsmith023]

Looking into where the issue could be coming from, I can isolate the problem to @grpc/grpc-js==1.13.4, which our package depends on through nice-grpc, as the following code hangs when I run with deno==2.4:

import grpc from '@grpc/grpc-js';
import protoLoader from '@grpc/proto-loader';

const packageDefinition = protoLoader.loadSync(
    import.meta.dirname + '/health.proto',
    {keepCase: true,
     longs: String,
     enums: String,
     defaults: true,
     oneofs: true
    });
const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);

const main = () => {
  console.log('Starting gRPC health check...');
  const stub = new protoDescriptor.grpc['health'].v1.Health('localhost:50051', grpc.credentials.createInsecure());
  stub.check(protoDescriptor.grpc['health'].v1.HealthCheckRequest, (error, response) => {
    if (error) {
      console.error('Error:', error);
    } else {
      console.log('Health Check Response:', response);
    }
  })
}

main()

and the cmd deno run --allow-env --allow-net --allow-read

Looking around at the landscape of other packages, it could be that we need to develop a deno-only package that uses its own deno-specific grpc transport implementation. Given some recent exploratory work into developing a browser-only client here: https://github.com/weaviate/typescript-client/pull/307, extending this work to also allow publishing a deno-only client would become achievable

[pamoller]

@all, thanks for reply. @malgamves always the latest deno version (deno 2.4.2). My investigation ended up on nice-grpc also. Maybe this helps @tsmith023 ??? https://github.com/denoland/deno/issues/23246#issuecomment-2144998810

[ben-laird]

There's also an open issue in Deno about supporting @grpc/grpc-js on server-side (#23714), whereas denoland/deno#23246 is more about supporting @grpc/grpc-js on client-side, judging from a brief skim of the two issues. Is denoland/deno#23714 the underlying problem? If so, would the Deno-specific client you mentioned @tsmith023 be deprecated when denoland/deno#23714 is fixed?

[Ipicon]

Looking into where the issue could be coming from, I can isolate the problem to @grpc/grpc-js==1.13.4, which our package depends on through nice-grpc, as the following code hangs when I run with deno==2.4:

import grpc from '@grpc/grpc-js'; import protoLoader from '@grpc/proto-loader';

const packageDefinition = protoLoader.loadSync( import.meta.dirname + '/health.proto', {keepCase: true, longs: String, enums: String, defaults: true, oneofs: true }); const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);

const main = () => { console.log('Starting gRPC health check...'); const stub = new protoDescriptor.grpc['health'].v1.Health('localhost:50051', grpc.credentials.createInsecure()); stub.check(protoDescriptor.grpc['health'].v1.HealthCheckRequest, (error, response) => { if (error) { console.error('Error:', error); } else { console.log('Health Check Response:', response); } }) }

main() and the cmd deno run --allow-env --allow-net --allow-read

Looking around at the landscape of other packages, it could be that we need to develop a deno-only package that uses its own deno-specific grpc transport implementation. Given some recent exploratory work into developing a browser-only client here: #307, extending this work to also allow publishing a deno-only client would become achievable

Looking into where the issue could be coming from, I can isolate the problem to @grpc/grpc-js==1.13.4, which our package depends on through nice-grpc, as the following code hangs when I run with deno==2.4:

import grpc from '@grpc/grpc-js'; import protoLoader from '@grpc/proto-loader';

const packageDefinition = protoLoader.loadSync( import.meta.dirname + '/health.proto', {keepCase: true, longs: String, enums: String, defaults: true, oneofs: true }); const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);

const main = () => { console.log('Starting gRPC health check...'); const stub = new protoDescriptor.grpc['health'].v1.Health('localhost:50051', grpc.credentials.createInsecure()); stub.check(protoDescriptor.grpc['health'].v1.HealthCheckRequest, (error, response) => { if (error) { console.error('Error:', error); } else { console.log('Health Check Response:', response); } }) }

main() and the cmd deno run --allow-env --allow-net --allow-read

Looking around at the landscape of other packages, it could be that we need to develop a deno-only package that uses its own deno-specific grpc transport implementation. Given some recent exploratory work into developing a browser-only client here: #307, extending this work to also allow publishing a deno-only client would become achievable

Looking into where the issue could be coming from, I can isolate the problem to @grpc/grpc-js==1.13.4, which our package depends on through nice-grpc, as the following code hangs when I run with deno==2.4:

import grpc from '@grpc/grpc-js'; import protoLoader from '@grpc/proto-loader';

const packageDefinition = protoLoader.loadSync( import.meta.dirname + '/health.proto', {keepCase: true, longs: String, enums: String, defaults: true, oneofs: true }); const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);

const main = () => { console.log('Starting gRPC health check...'); const stub = new protoDescriptor.grpc['health'].v1.Health('localhost:50051', grpc.credentials.createInsecure()); stub.check(protoDescriptor.grpc['health'].v1.HealthCheckRequest, (error, response) => { if (error) { console.error('Error:', error); } else { console.log('Health Check Response:', response); } }) }

main() and the cmd deno run --allow-env --allow-net --allow-read

Looking around at the landscape of other packages, it could be that we need to develop a deno-only package that uses its own deno-specific grpc transport implementation. Given some recent exploratory work into developing a browser-only client here: #307, extending this work to also allow publishing a deno-only client would become achievable

After running with the following environment variables: GRPC_VERBOSITY=DEBUG GRPC_TRACE=all

I can confirm that it fails when creating a client, specifically when creating an internal-channel. Getting a skipped error in: node_modules/.deno/@[email protected]/node_modules/@grpc/grpc-js/build/src/internal-channel.js:297:23

Seems that @grpc/[email protected] works fine