Представьте, после изменения gRPC-Go сборка, runtime или интеграция стали нестабильными. Как вы будете расследовать проблему?

Расследование нестабильности после изменения gRPC-Go

Нестабильность после изменения может проявляться в трёх формах: сборка не проходит, runtime падает или паникует, интеграция ведёт себя непредсказуемо. Каждый случай требует своего подхода.

Нестабильность сборки

Сначала проверьте согласованность зависимостей. Обновление grpc-go часто требует одновременного обновления google.golang.org/protobuf и связанных пакетов.

# Покажет конфликты версий
go mod graph | grep -E 'google.golang.org/(grpc|protobuf)'

# Обновите согласованно
go get google.golang.org/grpc@latest
go get google.golang.org/protobuf@latest
go mod tidy

# Проверьте на ошибки импорта
go build ./...

Если ошибка связана с generated code (например, protoc-gen-go-grpc сгенерировал код под старый API), пересгенерируйте .pb.go файлы:

buf generate
# или
protoc --go_out=. --go-grpc_out=. proto/*.proto

Паники и runtime-ошибки

При panics первым делом включите full stack trace и проверьте, в каком goroutine паника:

GOTRACEBACK=all go run ./cmd/server 2>&1 | tee /tmp/panic.log

Паника в goroutine с префиксом google.golang.org/grpc — это баг в самой библиотеке или её некорректное использование. Паника в вашем коде внутри interceptor или handler — ваша ответственность. Добавьте recovery-interceptor:

func recoveryInterceptor(ctx context.Context, req interface{},
  info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
  defer func() {
    if r := recover(); r != nil {
      debug.PrintStack()
      err = status.Errorf(codes.Internal, "panic: %v", r)
    }
  }()
  return handler(ctx, req)
}

Нестабильность интеграции

Интеграционная нестабильность (flaky tests, intermittent errors) чаще всего вызвана race conditions. Запустите с детектором гонок:

go test -race ./...
go run -race ./cmd/server

Следующий шаг — проверка breaking changes в changelog grpc-go. Изменения в API часто документированы:

git log --oneline v1.63.0..v1.64.0 -- . # если работаете с форком
curl https://raw.githubusercontent.com/grpc/grpc-go/master/CHANGELOG.md | head -200

Бинарный поиск для локализации изменения

Если нестабильность появилась после серии коммитов, используйте git bisect с автоматическим тестом:

git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>
git bisect run sh -c 'go build ./... && go test -count=3 ./... -run TestIntegration'

Профилирование для выявления деградации производительности

// Запустите pprof endpoint в сервере
import _ "net/http/pprof"

go func() {
  log.Println(http.ListenAndServe("localhost:6060", nil))
}()

# Снимите профиль до и после
go tool pprof http://localhost:6060/debug/pprof/heap > before.pb
# После изменения:
go tool pprof http://localhost:6060/debug/pprof/heap > after.pb
go tool pprof -diff_base before.pb after.pb

Проверка изменений в generated code

Generated .pb.go файлы должны быть пересозданы при обновлении protoc-gen-go-grpc. Несовпадение версий плагина и runtime — источник subtle bugs:

# Зафиксируйте версии плагинов в tools.go
cat tools.go
// go:build tools
package tools
import (
  _ "google.golang.org/grpc/cmd/protoc-gen-go-grpc"
  _ "google.golang.org/protobuf/cmd/protoc-gen-go"
)

Подводные камни

• go mod tidy может молча downgrade транзитивные зависимости — после него всегда запускайте полный тест-сюит, не только сборку.
• Generated код (.pb.go) в git может расходиться с версией protoc-плагина на CI — добавьте шаг проверки через buf lint и buf breaking в пайплайн.
• -race детектор увеличивает латентность в 5–10 раз — не используйте его в production, только в тестах и локально.
• Изменение в ServiceConfig (retry policy, load balancing) вступает в силу не мгновенно — клиент кэширует конфигурацию и обновляет её при переподключении.
• codes.Unavailable после обновления может означать, что сервер ещё не поднялся, а не баг в библиотеке — добавьте wait-for-ready в тесты.
• Interceptor-цепочка применяется в строго определённом порядке — изменение порядка регистрации в grpc.NewServer(...) ломает поведение без очевидной ошибки.
• Изменение дефолтного значения MaxConcurrentStreams в новой версии grpc-go может неожиданно ограничить пропускную способность под нагрузкой.
• При обновлении grpc-go проверяйте CHANGELOG на изменения в экспериментальных API (пакет experimental/) — они меняются без соблюдения semver.

• Сразу обвинять gRPC-Go, не проверив соседние слои системы
• Чинить симптом без минимального воспроизведения и evidence
• Не учитывать версии, конфигурацию, окружение и recent changes

• Умеет локализовать проблему вокруг gRPC-Go
• Двигается от симптома к гипотезам и проверкам
• Отличает баг инструмента от ошибки использования или окружения