Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

DAPR_* environment variables are snapshotted at import time, so loading config after import silently dials localhost

Abierto
  • ¿Algo no está bien?
#1,259 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 7 días

@CasperGN ya está trabajando en esto.

Desde el 9/10/2026.

  • #1262 de @CasperGN — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start with the dapr.conf settings module, which reads the DAPR_* variables at import, and with dapr.conf.helpers.GrpcEndpoint, which builds the endpoint from them. Run the reproduction in the issue to confirm the value stays None after os.environ changes. Done means either the settings are read when a client is constructed, or a clear error or warning is raised when os.environ and the snapshot disagree. The issue leaves the choice between these options to the maintainers, so confirm the approach before writing code.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happens

dapr.conf.settings reads the DAPR_* environment variables when the module is
first imported. Setting them afterwards has no effect, and the SDK silently
falls back to dns:localhost:50001 instead of the configured endpoint. There is
no warning and no error — the first symptom is a connection failure that looks
like a network or platform problem.

This is easy to hit with any of the common config patterns: python-dotenv in a
config.py, a settings module, a CLI that parses args before wiring the client,
or a framework that imports your package before your .env loader runs.

Reproduction

import os
assert "DAPR_GRPC_ENDPOINT" not in os.environ

import dapr.conf as conf
print(conf.settings.DAPR_GRPC_ENDPOINT)    # None

os.environ["DAPR_GRPC_ENDPOINT"] = "https://grpc-example.example.com:443"
print(os.environ["DAPR_GRPC_ENDPOINT"])    # the value we just set
print(conf.settings.DAPR_GRPC_ENDPOINT)    # None  <-- still

from dapr.conf.helpers import GrpcEndpoint
ep = GrpcEndpoint(conf.settings.DAPR_GRPC_ENDPOINT
                  or f"localhost:{conf.settings.DAPR_GRPC_PORT}")
print(ep.endpoint)                         # dns:localhost:50001

Observed output:

1. imported dapr.conf with no DAPR_GRPC_ENDPOINT set
   settings.DAPR_GRPC_ENDPOINT = None
   settings.DAPR_GRPC_PORT     = 50001

2. set DAPR_GRPC_ENDPOINT AFTER import
   os.environ value            = https://grpc-example.example.com:443
   settings.DAPR_GRPC_ENDPOINT = None

3. endpoint the SDK would dial: dns:localhost:50001

Expected

Any of the following would have saved the debugging time:

  1. Read the setting lazily, at client construction, rather than at import.
  2. Keep the import-time read, but re-check os.environ when a client is built
    and raise or warn on a mismatch between os.environ["DAPR_GRPC_ENDPOINT"]
    and settings.DAPR_GRPC_ENDPOINT.
  3. Document it prominently in the client docs — "set DAPR_* before importing
    dapr" — since the current failure mode is silent.

(1) seems best; (2) is the cheapest thing that makes the failure loud.

Environment

  • dapr 1.18.3, dapr-ext-workflow 1.18.3
  • Python 3.12.12, macOS 15 (darwin 24.3.0)
  • Talking to a managed Dapr control plane over a remote gRPC endpoint, so the
    localhost fallback can never succeed

Why it matters

Against a local sidecar the fallback is often correct, which is why this is
rarely noticed. Against any remote or managed endpoint it is always wrong, and
the error surfaces far from its cause — the one I chased presented as "every
connection fails", with correct-looking values in .env and in os.environ.

Lenguaje dominante
Python
Estrellas
274
Forks
157
Merge medio
8 d 20 h
PR fusionados (30 d)
31

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dapr/python-sdk

Todos los issues de dapr/python-sdk

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.