如何在REST API运行期间触发bidiStream gRPC API重发消息以触发响应

你的核心问题是执行顺序逻辑错误：原脚本里REST请求是同步执行的，会一直阻塞到它返回才会运行后续的during块，但REST恰好需要等待gRPC发送消息才会返回——这就形成了死锁：REST等gRPC消息，gRPC消息要等REST执行完才发送。

必须把REST请求和gRPC消息发送改成并发执行，让REST发起后，gRPC的消息能及时发送触发其返回。

修改后的脚本示例 #

exec(
  fromClientSide
    .connect
    .header(metadataObject.Authorization)(s"Bearer ${metadataObject.TokenKey}")
    .callOptions(CallOptions.DEFAULT.withDeadlineAfter(30, TimeUnit.SECONDS))
    .endCheck(statusCode is Status.Code.OK)
)
.exec(
  fromClientSide.send(WarmUp_Msg)
)
.pause(200)
// 并行执行REST请求和gRPC消息发送，打破死锁
.parallel(
  // 分支1：发起REST请求，会阻塞直到收到响应
  exec(REST_API_HERE),
  // 分支2：短暂等待确保REST已发起，再发送gRPC触发消息
  exec(
    pause(500) // 时间可根据实际接口启动延迟调整
      .exec(fromClientSide.send(request_Msg))
  )
)
// 后续处理gRPC消息确认
.exec(fromClientSide.reconciliate(waitFor = NextMessage))

关键调整说明 #

• 用parallel实现并发：parallel块内的两个分支会同时启动，REST请求发起后不需要等待它返回，另一个分支就能立刻执行gRPC消息发送，触发REST的响应。
• 新增短等待：分支2里的pause(500)是为了避免gRPC消息发送太早，保证REST请求已经成功发起，时间可以根据实际接口的启动速度调整。
• 简化during逻辑：你的场景只需要一次gRPC消息触发REST返回，所以不用during循环，直接pause + send更直接。如果需要在REST等待期间持续发送消息，也可以把分支2改成这样：

during(10) { // 持续10秒循环发送gRPC消息
  exec(fromClientSide.send(request_Msg))
    .pause(100) // 每隔100毫秒发一次
}

内容的提问来源于stack exchange，提问作者TriNguyen