Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[OFREP] Should variant and reason tolerate what the spec makes optional?

未关闭
  • 哪里不对？
#418 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
api, backend

调研方向

从 ofrep/init.py 中构造 FlagResolutionDetails 的位置开始，阅读周围的响应映射代码。检查 types.md 中可选字段的定义，以及所引用的 OFREP 提供商要求。当不含 variant 的响应和包含非标准 reason 字符串的响应都能在不意外触发 KeyError 的情况下得到处理，并且两个案例都有覆盖时，即视为完成。

由索引模型根据 Issue 内容生成。

描述

question

Two questions about the same three lines in ofrep/__init__.py, both about optional fields being indexed unconditionally. Asking rather than reporting, in case either is a deliberate strictness choice.

value = data.get("value", default_value)      # tolerant
_typecheck_flag_value(value, flag_type)

return FlagResolutionDetails(
    value=value,
    reason=Reason[data["reason"]],            # (2)
    variant=data["variant"],                  # (1)
    flag_metadata=data.get("metadata", {}),
)

value is read with a default; the two below it are not. That asymmetry is what makes me think the others might be oversights rather than intent.

1. variant is optional, but indexed

types.md types it variant (string, optional), and OFREP's evaluationSuccess requires only key and reason.

Observed against flagd-testbed:v3.8.0:

$ curl -s -X POST localhost:8016/ofrep/v1/evaluate/flags/disabled-boolean-flag -d '{"context":{}}'
{"key":"disabled-boolean-flag","reason":"DISABLED","metadata":{}}     HTTP 200

KeyError: 'variant', surfacing to the application as GENERAL. Note value is already handled correctly for this response — OFREP's codeDefaultFlag schema omits value on purpose ("The provider must use the code default value when processing this response"), and data.get("value", default_value) does exactly that. So the response is understood apart from the variant.

This is not specific to disabled flags: any response omitting variant would do it.

Question: should this be data.get("variant"), or is there a reason to require the field?

2. Reason[...] is an enum lookup by name

Reason[data["reason"]] raises KeyError for any reason outside the nine members of Python's Reason enum. But Requirement 2.2.5 permits a provider to populate reason with one of the listed values "or some other string indicating the semantic reason for the returned flag value", and types.md adds:

The reason should not be limited to the reasons enumerated above. It can be any of the pre-defined reasons, or any string value.

The Python SDK models this correctly — FlagEvaluationDetails.reason is typed str | Reason | None. So an OFREP server returning a vendor-specific reason string appears to crash this provider on a response the specification explicitly allows.

I have not observed this one in the wild — flagd only returns standard reasons — so it is inference from the code, not a reproduction. Flagging it because it is the same line and the same class of thing.

Question: should the reason fall back to the raw string when it is not a known member, rather than raising?

Context

Found while building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated @disabled-flags capability exposed (1); (2) came from reading the surrounding lines. For calibration, the Go and JavaScript OFREP providers pass the same scenarios, so this does not look like a limitation of OFREP.

Happy to be told either of these is intended.

主要语言
Python
星标
27
派生
33
平均合并
1 天 11 小时
30 天内合并 PR
20

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

open-feature/python-sdk-contrib 的其他 Issue

查看 open-feature/python-sdk-contrib 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。