Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#1,259 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

@CasperGN がすでに取り組んでいます。

2026年10月9日 から。

  • #1262 @CasperGN による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
274
フォーク
157
平均マージ
9日 5時間
マージ済み PR（30日）
30

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dapr/python-sdk のほかの issue

dapr/python-sdk の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。