Is InMemoryFlag.state intended to be honoured? DISABLED is never read

openfeature/provider/in_memory_provider.py の InMemoryFlag.state と resolve() から開始し、issue に記載されている無効化されたフラグの言語間での文書化された動作を比較します。Python が DISABLED を考慮すべきか、それとも互換性のためだけにフィールドを保持すべきかを確認します。意図する動作が決定されて記録され、maintainers が変更を選択した場合は、関連する in-memory provider の動作またはテストが更新されていれば完了です。

InMemoryFlag declares a state field with an ENABLED/DISABLED enum, and as far as I can tell nothing ever reads it. Asking because "the field is there for API compatibility and honouring it was never promised" is a perfectly good answer, and I would rather have it recorded than assume a bug.

What I see

openfeature/provider/in_memory_provider.py:

class InMemoryFlag(typing.Generic[T_co]):
    class State(StrEnum):
        ENABLED = "ENABLED"
        DISABLED = "DISABLED"

    default_variant: str
    variants: dict[str, T_co]
    flag_metadata: FlagMetadata = field(default_factory=dict)
    state: State = State.ENABLED        # line 47
    ...

    def resolve(self, evaluation_context):
        if self.context_evaluator:
            return self.context_evaluator(self, evaluation_context or EvaluationContext())
        return FlagResolutionDetails(
            value=self.variants[self.default_variant],
            reason=Reason.STATIC,
            variant=self.default_variant,
            flag_metadata=self.flag_metadata,
        )

grep -n state in_memory_provider.py returns exactly one line — the declaration above. State.DISABLED does not appear anywhere else in the package.

So a flag constructed with state=State.DISABLED resolves to its own defaultVariant with reason STATIC, as though it were enabled.

Why I think it may be worth changing

For comparison, across the other in-memory reference providers:

Two of the four substitute the caller's default with reason: DISABLED and no error; Go agreed that was the right answer when it was raised. That is convention rather than specification — I could find no numbered requirement saying what a provider owes a disabled flag — so this is not a conformance claim, just a consistency observation.

Also worth noting the two shapes in the ecosystem: state: ENABLED|DISABLED in Go, Python and flagd's flag format, versus disabled: boolean in JavaScript, Java and Appendix B's test-flags.json. Not something to fix here, but it is why the field probably exists in this shape.

Questions

1. Is state intended to be honoured by resolve(), or is it carried for configuration compatibility only?
2. If it should be honoured — is the intended behaviour the caller's default with reason: DISABLED and no error code, matching JavaScript and Java?
3. Would you rather the field were removed than implemented, if honouring it is not wanted? A declared field that is never read seems the more surprising of the two states.

Context

Found while building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated @disabled-flags capability is left undeclared for the Python in-memory suites on the strength of this, and the four scenarios skip rather than fail — so nothing is blocked. Recording the question so the reason for that gate is not just in my head.