context en database/sql y gRPC

database/sql y google.golang.org/grpc fueron diseñados en torno a context.Context desde el primer día.

Pasar ctx a los métodos de consulta y RPC vincula el trabajo de la base de datos y la red al mismo árbol de cancelación que tu manejador HTTP.

Resumen

Usa QueryContext, ExecContext y BeginTx con context para cada llamada a la base de datos con ámbito de solicitud.

Los métodos cliente y servidor de gRPC aceptan ctx como el primer argumento; las fechas límite se propagan como tiempos de espera de RPC.

Los RPCs de streaming deben verificar ctx.Done() entre las llamadas Recv y Send.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

func GetOrder(ctx context.Context, db *sql.DB, id string) (string, error) {
    var status string
    err := db.QueryRowContext(ctx, `SELECT status FROM orders WHERE id = ?`, id).Scan(&status)
    return status, err
}

Cuándo usar esto:

• Reemplaza Query/Exec sin Context en cualquier ruta de código accesible desde manejadores HTTP o gRPC.
• Pasa el context del manejador o interceptor a los stubs gRPC sin cambios, excepto por tiempos de espera hijos más cortos.
• Cancela los bucles de streaming cuando ctx.Done() se active para evitar fugas de goroutines.

Ejemplo de Trabajo

package main
 
import (
    "context"
    "database/sql"
    "fmt"
    "time"
 
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
 
    _ "github.com/mattn/go-sqlite3"
)
 
func queryStatus(ctx context.Context, db *sql.DB) (string, error) {
    ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
    defer cancel()
    var s string
    err := db.QueryRowContext(ctx, `SELECT 'shipped'`).Scan(&s)
    return s, err
}
 
func dialGRPC(ctx context.Context) (*grpc.ClientConn, error) {
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()
    return grpc.DialContext(ctx, "localhost:50051",
        grpc.WithTransportCredentials(insecure.NewCredentials()),
    )
}
 
func main() {
    db, _ := sql.Open("sqlite3", ":memory:")
    defer db.Close()
 
    parent, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
    defer cancel()
 
    status, err := queryStatus(parent, db)
    fmt.Println(status, err)
 
    _, err = dialGRPC(parent)
    fmt.Println("grpc dial:", err)
}

Lo que esto demuestra:

• QueryRowContext respeta la cancelación del padre y el tiempo de espera hijo local.
• grpc.DialContext se bloquea solo hasta que el context termina o la conexión tiene éxito.
• Los tiempos de espera hijos se reducen dentro del presupuesto del padre para cada subsistema.
• El controlador SQLite aquí ilustra el patrón; los pools de producción usan la misma API con controladores Postgres/MySQL.

Inmersión Profunda

Cómo Funciona

• database/sql pasa el context a las interfaces QueryerContext del controlador; el comportamiento de cancelación depende del soporte del controlador.
• La adquisición del pool de conexiones respeta el context: el agotamiento lento del pool devuelve cuando ctx termina en lugar de bloquearse para siempre.
• Los objetos Tx usan BeginTx(ctx, opts); commit y rollback son rápidos, pero las sentencias en curso ya deberían usar el context de la tx.
• gRPC codifica las fechas límite en metadatos; los servidores deben fallar rápidamente con codes.DeadlineExceeded cuando queda tiempo insuficiente.

Superficie de API de database/sql

Patrón de Streaming gRPC

func consume(stream pb.Service_StreamServer) error {
    ctx := stream.Context()
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        default:
        }
        msg, err := stream.Recv()
        if err != nil {
            return err
        }
        _ = msg
    }
}

Los flujos de servidor exponen Context(); los flujos de cliente aceptan el ctx del llamador en la invocación inicial del RPC.

Nota sobre controller-runtime

Las llamadas al cliente de Kubernetes desde los reconciliadores deben pasar el context de reconciliación a las solicitudes de API para que laswatches se detengan cuando el gestor se apaga.

Trampas

• Usar Query sin Context en manejadores - Las solicitudes HTTP abandonadas mantienen vivo el trabajo de la base de datos. Solución: prohibir métodos que no sean de Context en la revisión para rutas de solicitud.
• Transacciones largas sin fecha límite - Bloqueos retenidos después de que el cliente se va. Solución: BeginTx con ctx; mantener las transacciones cortas.
• Ignorar ctx en bucles Recv de stream - Los flujos de servidor se filtran después de que el cliente se desconecta. Solución: seleccionar en ctx.Done() o manejar los errores de Recv rápidamente.
• grpc.Dial en lugar de DialContext - Sin cancelación durante el descubrimiento de servicios o el handshake TLS. Solución: siempre DialContext con ctx limitado.
• Tiempo de espera hijo mayor que la fecha límite de gRPC - El servidor puede abortar antes de lo que el cliente espera. Solución: leer ctx.Deadline() en el lado del servidor y ajustar el trabajo.
• Asumir que todos los controladores cancelan instantáneamente - Algunos controladores cancelan solo entre viajes de ida y vuelta de red. Solución: combinar el context con tiempos de espera de sentencias en SQL cuando sea necesario.

Alternativas

Preguntas Frecuentes

Relacionado

• Propagación de Cancelación en Manejadores HTTP - dónde comienza el ctx de DB
• Fechas Límite y Tiempos de Espera a Través de los Límites del Servicio - presupuestos por salto
• Probar Código Que Acepta context.Context - fakes y tiempos de espera
• Valores de Context: Cuándo y Cuándo No - metadatos gRPC vs valores
• Mejores Prácticas del Paquete Context - convenciones SQL y RPC

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado GC de Green Tea, go fix modernizers - verifica el parche en la compilación), chi (última - verifica en la compilación), gin (última - verifica en la compilación), echo (última - verifica en la compilación), google.golang.org/grpc (última - verifica en la compilación), sigs.k8s.io/controller-runtime (última - verifica en la compilación), kubebuilder (última - verifica en la compilación), tinygo (última - verifica los objetivos de la placa en la compilación), wazero (última - verifica en la compilación) y golangci-lint (última - verifica el conjunto de linters en la compilación). 49454e4f4d5f434e4f5904434556494d43451e1b1256181a181c1a1d