[BUG]用 examples 里面的机器人，grpc startGrpcStream 出错

[fxmumu]

Runtime environment

• Server: Starting Docker Container for Wechaty v1.20.2 with Node.js v16.20.1 ...

Console output time="2024-04-11 09:48:28.393" level=error msg="puppet start err: PuppetService Start() rejection: startGrpcStream err:rpc error: code = Unavailable desc = connection closed before server preface received" module=wechaty panic: PuppetService Start() rejection: startGrpcStream err:rpc error: code = Unavailable desc = connection closed before server preface received

[dosubot[bot]]

Hey there, @fxmumu! 👋 I'm Dosu, your friendly neighborhood bot here to lend a hand with bugs, answer your questions, and guide you through contributing while we wait for a human maintainer to swing by. I'm diving into your issue now and will get back to you with a full answer shortly. Hang tight!

[fxmumu]

go-wechaty example bot 运行时，服务端有一条日志： 09:48:26 INFO Io on(jsonrpc): [object Object]

[dosubot[bot]]

The error you're encountering with startGrpcStream suggests a problem with the gRPC connection, likely due to TLS configuration issues or a mismatch in security settings. Here's how you can address it:

1. Check TLS Configuration: Ensure your TLSConfig is correctly set up with valid CaCert and ServerName. These must match the server's settings you're trying to connect to.

2. Disable TLS for Debugging: Temporarily disable TLS in your TLSConfig by setting Disable to true. This can help determine if the issue is with TLS. Remember, this is only for debugging; always use TLS in production.

3. Review gRPC Connection Settings: Make sure GrpcReconnectInterval and Authority are correctly configured. Incorrect settings here can lead to connection failures.

4. Update Dependencies: Ensure all dependencies, including go-wechaty and gRPC, are up to date to avoid compatibility issues.

5. Docker Network Configuration: Verify that Docker's network settings allow for communication with the gRPC server. Check for any network isolation or firewall rules that might be blocking the connection.

6. Increase Logging: More detailed logs from both the client and server can provide further insights into what might be causing the connection issue.

For a quick reference, here's how you might adjust your TLS configuration for debugging:

options := puppetservice.Options{
    TLS: puppetservice.TLSConfig{
        Disable: true, // Only for debugging, ensure TLS is enabled in production
        CaCert: "/path/to/ca.crt",
        ServerName: "server.name",
    },
    // Other options
}

Additionally, a similar issue was addressed in the go-wechaty repository by disabling the gateway's TLS for debugging with the environment variable WECHATY_PUPPET_SERVICE_NO_TLS_INSECURE_SERVER=true during the Docker run command. This might be a workaround to consider.

If these steps do not resolve your issue, please provide more details about your setup for further assistance.

Sources

• [BUG] puppet start err: PuppetService Start() rejection: startGrpcStream err:rpc error: code = Unavailable desc = connection closed before server preface received module=wechaty
• wechaty-puppet-service/options.go
• VERSION

#### About Dosu

This response is meant to be useful and save you time. It is **not meant to be a precise solution**, but rather a starting point for your own research. Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant. If you want to continue the conversation, start your reply with @dosu-bot.

[fxmumu]

The error you're encountering with startGrpcStream suggests a problem with the gRPC connection, likely due to TLS configuration issues or a mismatch in security settings. Here's how you can address it:

1. Check TLS Configuration: Ensure your TLSConfig is correctly set up with valid CaCert and ServerName. These must match the server's settings you're trying to connect to.
2. Disable TLS for Debugging: Temporarily disable TLS in your TLSConfig by setting Disable to true. This can help determine if the issue is with TLS. Remember, this is only for debugging; always use TLS in production.
3. Review gRPC Connection Settings: Make sure GrpcReconnectInterval and Authority are correctly configured. Incorrect settings here can lead to connection failures.
4. Update Dependencies: Ensure all dependencies, including go-wechaty and gRPC, are up to date to avoid compatibility issues.
5. Docker Network Configuration: Verify that Docker's network settings allow for communication with the gRPC server. Check for any network isolation or firewall rules that might be blocking the connection.
6. Increase Logging: More detailed logs from both the client and server can provide further insights into what might be causing the connection issue.

For a quick reference, here's how you might adjust your TLS configuration for debugging:

options := puppetservice.Options{
    TLS: puppetservice.TLSConfig{
        Disable: true, // Only for debugging, ensure TLS is enabled in production
        CaCert: "/path/to/ca.crt",
        ServerName: "server.name",
    },
    // Other options
}

Additionally, a similar issue was addressed in the go-wechaty repository by disabling the gateway's TLS for debugging with the environment variable WECHATY_PUPPET_SERVICE_NO_TLS_INSECURE_SERVER=true during the Docker run command. This might be a workaround to consider.

If these steps do not resolve your issue, please provide more details about your setup for further assistance.

Sources

• [BUG] puppet start err: PuppetService Start() rejection: startGrpcStream err:rpc error: code = Unavailable desc = connection closed before server preface received module=wechaty
• wechaty-puppet-service/options.go
• VERSION

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

yeah, I set WECHATY_PUPPET_SERVICE_NO_TLS_INSECURE_SERVER=true for gateway, and disable tls in grpc client, resolved, 3Q