Resolves a configurable seam, per process rather than per node.

Every seam in this family that a consumer's tests may need to vary goes through here — which fake is in play, what that fake returns, which rate limiter is active, anything added later. There is one resolver so that five venue packages cannot each invent a variant of it.

Why this is not Application.get_env/3

Application.put_env/3 is node-wide. A consumer running async: true — which is every well-built Elixir suite — has many tests on one node at once, so a test that configures a seam globally configures it for every other test running beside it.

That is not hypothetical. In the application these packages were extracted from, seven tests set a global rate-limiting flag for their duration, and for that duration every other async test on the node was suddenly metered against a one-request bucket. An unrelated WebSocket test came back {:error, {:rate_limited, 1}} while asserting on connection errors. The failure was silent, intermittent and seed-dependent — the worst combination, and it cost a day to find.

Lookup order

1. Process.get/1 in the calling process — the override a test set for itself.
2. The $callers ancestor chain. ExUnit propagates :"$callers" to spawned Tasks, so a task launched inside a test finds the override the test set without the test threading it through every closure. This is the step that gets omitted, and omitting it makes the seam work in simple tests and fail in exactly the concurrent ones it exists for.
3. Application.get_env/3 — the global default. This is what production reads and what a consumer configures normally; the process-scoped steps are a test affordance layered above it, not a replacement.

Crossing a process boundary

A GenServer runs in its own process and will not find the caller's dictionary at all, because it is not in the caller's $callers chain. Resolve in the caller and put the answer in the message — snapshot/1 on the way in, resolve_snapshot/4 on the way out. Resolving inside the server is too late, and it fails in the direction that looks like it works: production is unaffected, so only the consumer's async suite breaks.

Examples

# Production: reads application env, as normal.
Config.get(:dp_exchange_core, :rate_limit_module, DefaultRateLimiter)

# A test, for its own process tree only:
Config.put_override(:rate_limit_module, AlwaysRateLimited)

opt/3 — the same problem, one layer down

This module resolves seams — where consumer configuration meets Core. opt/3 fixes a related but distinct trap that lives in keyword() options passed on individual calls, not in application config: Keyword.get/3 only substitutes its default for an ABSENT key, never for a key that is present and nil.

That distinction is invisible reading the code and is reachable on every call, because every venue package in this family forwards its own opts unchanged, by convention, through several layers — a Feed passes its opts to PollingFeed.start_link/1, which never itself set interval_ms. When the venue's own caller never configured a key either, it does not vanish; it arrives as key: nil, explicit and present, because something upstream did Keyword.get(callers_opts, :interval_ms) with no default and handed the nil straight through.

Keyword.get(opts, :interval_ms, 30_000) against interval_ms: nil returns nil, not 30_000 — the default silently does not apply. This was fixed once, by hand, at exactly one call site (PollingFeed's :start_delay_ms, with an incident recorded in its own comment) and left open everywhere else that mattered: PollingFeed's :interval_ms crashed Process.send_after/3 outright; HttpClient's :retry_attempts was worse — a nil compares as greater than any integer in Erlang term ordering, so it silently entered the retry branch and then died computing 4 - nil, killing the calling venue process, which this library does not supervise.

opt/3 is Keyword.get/3 with that one difference: a present-and-nil value is treated the same as an absent one. It does not use ||, because || is falsy on false too — an explicit log_requests: false or raw_status: false must survive, and a helper that silently overrode a real false back to its default would be the same bug in the other direction.