Golang调用Storage Write API AppendRows循环卡死问题

这个永久阻塞是Go版BigQuery Storage Write SDK的managedwriter包流控机制导致的，和你把AppendResult追加到切片的操作本身无关，核心问题是没有及时消费Append返回的结果句柄，触发了SDK的未完成请求上限拦截：

• AppendRows本身是异步接口，调用时只会把数据放到发送队列，不会等待服务端确认写入，返回的*AppendResult是用来接收服务端响应的future句柄
• SDK为单个ManagedStream维护了固定容量的在途请求队列，默认最多同时存10个未确认的写入请求，一旦队列占满，新的AppendRows调用会直接阻塞，直到队列里有旧请求被确认完成、腾出槽位
• 你把所有AppendResult攒到切片里全程不调用Ready()或GetResult()消费响应，第一次循环的请求占满队列后，第二次循环调用AppendRows就会直接卡住
• 删掉append结果的代码能跑是偶发现象：不持有AppendResult引用时，GC可能随机回收未处理的结果对象，间接释放队列槽位，这个行为完全不可靠，不能作为生产用法。

不要等所有请求发送完成后再统一处理结果，每发起一次Append就同步或异步消费结果，避免流控队列被打满，以下是两种可直接落地的写法：

同步逐批确认（适合一致性要求高的批量写入场景） #

每发送完一批就立刻等待服务端确认，写入成功后再发下一批，代码改动最小：

for i := 0; i < len(skus); i = i + PFStocksLimit {
    lim := i + PFStocksLimit
    if lim > len(skus)-1 {
        lim = len(skus) - 1
    }
    stocks := getStocks(skus[i:lim])
    pfProto := prepProto(gd, stocks)

    res, err := ms.AppendRows(ctx, pfProto)
    if err != nil {
        log.Fatalf("AppendRows call error: %v", err)
    }
    // 阻塞等待当前批次写入完成，释放流控队列槽位
    _, err = res.GetResult(ctx)
    if err != nil {
        log.Fatalf("batch write failed: %v", err)
    }
}

异步并发消费（适合高吞吐写入场景） #

发送请求和结果处理并行执行，不阻塞循环发批逻辑，同时保证所有写入结果都被正常消费：

import "sync"

var wg sync.WaitGroup
for i := 0; i < len(skus); i = i + PFStocksLimit {
    lim := i + PFStocksLimit
    if lim > len(skus)-1 {
        lim = len(skus) - 1
    }
    stocks := getStocks(skus[i:lim])
    pfProto := prepProto(gd, stocks)

    res, err := ms.AppendRows(ctx, pfProto)
    if err != nil {
        log.Fatalf("AppendRows call error: %v", err)
    }
    wg.Add(1)
    // 启动独立协程等待当前批次写入结果，不阻塞主循环发请求
    go func(r *managedwriter.AppendResult) {
        defer wg.Done()
        _, err := r.GetResult(ctx)
        if err != nil {
            log.Printf("batch write failed: %v", err)
        }
    }(res)
}
// 所有请求发送完成后，等待全部批次写入确认
wg.Wait()

• 默认流控配置下单流最多支持10个在途未确认请求，如果单批数据量小、需要更高吞吐，可以在初始化ManagedStream时通过managedwriter.WithMaxInflightRequests()、managedwriter.WithMaxInflightBytes()两个参数自定义在途请求上限，匹配业务的吞吐量需求
• 绝对不要依赖GC回收未持有引用的AppendResult来释放队列槽位，这个行为没有任何版本兼容性保障，生产环境会随机出现阻塞、写入丢失等难以排查的问题
• 如果写入时需要做错误重试，一定要基于AppendResult返回的响应做判断，不要盲目重复调用AppendRows，避免出现数据重复写入的问题。

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