[kinyoklion]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions (run locally on OTP 25.3; CI covers the rest)

Related issues

Found while reviewing #202. The fix is independent of that PR and applies to its branch unchanged (the evaluator is not modified there).

Describe the solution you've provided

Evaluating a flag with an invalid context (a missing key, or a kind or key that is not a binary) only validated the context once the flag had been found. When the flag was unknown or deleted, or when evaluating it raised, the evaluator still created a feature event carrying the invalid context, and the event server crashed when it derived the context's canonical key for index-event deduplication.

Each such evaluation lost the buffered events and the open summary. A burst of them exceeded the event supervisor's restart intensity and restarted the instance supervisor, which comes back without its feature store and update processor while initialized/1 still returns true. With the synchronous add_event on main the caller at least saw the exit; with the asynchronous pipeline in #202 the failure is silent.

Every place that creates an event now validates the context first. The unknown-flag, deleted-flag and exception results go through one helper (unknown_flag_result/4) that returns the default value with {error, user_not_specified}, logs a warning and records no event when the context is invalid, as the other server-side SDKs do. The known-flag path keeps its existing check in flag_for_context_check_valid/5 and now logs the same warning. A valid context is validated exactly once per evaluation, so the known-flag path costs the same as before; the unknown-flag path pays one is_valid/2 call (about 130 ns for a single-kind context) on top of the warning it already logs. ldclient_context:is_valid/2 is wrapped so a term that is not a context at all counts as invalid instead of raising.

Tests: unknown_flag_with_invalid_context (five invalid shapes against an unknown, a deleted and a known flag), exception_with_invalid_context_sends_no_event (the feature store raising, as it does once the store has been lost; a valid context keeps the existing exception event, an invalid one records nothing) and invalid_context_does_not_crash_the_event_server (public API; the event server keeps its pid and still delivers afterwards). All three fail on main without the change.

Describe alternatives you've considered

Checking the context once at the top of flag_key_for_context/4 is simpler to reason about but validates known flags twice (the per-flag check is still needed by all_flags_state, which calls the lower-level function directly) and changes the result for an invalid context on an offline or not-yet-initialised instance from client_not_ready to user_not_specified. Guarding ldclient:variation/4 and variation_detail/4 the way identify and track already do would cover the public API but not internal callers. Making the event server tolerate a bad context would hide the error from the caller and would have to be done separately on main and in #202.

Additional context

Also reproducible with ldclient:variation(<<"missing-flag">>, #{kind => <<"org">>, key => 42}, false).

---

Note

Overview
Invalid contexts no longer emit analytics events on unknown-flag, deleted-flag, or evaluation-exception paths—preventing the event server from crashing when it canonicalizes a bad context.

Evaluation now routes those outcomes through unknown_flag_result/4, which checks is_valid_context/1 first. Valid contexts keep prior behavior (including unknown-flag events and warnings for flag_not_found). Invalid contexts use shared invalid_context_result/2: default value, {error, user_not_specified}, a warning, and no events—aligned with the known-flag path and other server SDKs.

The exception handler in flag_key_for_context/4 uses the same helper instead of always building an unknown-flag event. flag_for_invalid_context now logs the same invalid-context warning via invalid_context_result.

Tests cover invalid context shapes against unknown/deleted/known flags, exception + invalid context (no event), and that the event server stays alive through the public API.

^{Reviewed by Cursor Bugbot for commit 5315a2c. Bugbot is set up for automated code reviews on this repo. Configure here.}