A React app renders <AuthContext value={session}> near the root, yet a deep child's useContext(AuthContext) keeps returning the createContext default. The provider is definitely mounted above that child. What identity problem should you suspect, and how would you confirm it?

## Why identity is the thing to check `createContext` returns an object, and that object *is* the key. When a component calls `useContext(AuthContext)`, React walks up its ancestors and compares each provider's context object against the one it was handed. The comparison is reference equality. Nothing about the variable name, the display name, or the shape of the value participates. So "a provider is mounted above me but I read the default" has one honest meaning: the provider above is for a *different object* than the one the consumer asked about. Once you accept that, the search narrows to how two objects came to exist. ```js // module evaluated twice => two distinct objects export const AuthContext = createContext(null); ``` ## How a module ends up evaluated twice - **Duplicated package instance.** The provider and the consumer resolve the same package from two different locations in the dependency tree, so its module graph is instantiated twice and every module-level `createContext` runs twice. - **Dual-format shipping.** A package publishes both an ESM and a CommonJS build; one importer gets one, another gets the other, and each build has its own module instance. - **Monorepo resolution.** A workspace package is consumed both through its published entry point and through a direct deep path, producing two distinct modules with the same source. - **Two copies of React.** Rarer but worse: a library bundles its own React rather than treating it as a peer, so its hooks run against a different renderer. Context breakage is one symptom among several — you usually also see invalid-hook-call errors. - **Accidental re-creation.** A `createContext` call sitting inside a component or a factory rather than at module scope makes a fresh context object on every call. Any consumer holding a reference to a different call's result never matches. That last one is worth checking first because it needs no bundler knowledge to spot: `createContext` belongs at module scope, evaluated once. ## Confirming it, cheaply The direct test is a reference comparison. Import the context object from both suspect paths into a single scratch module and compare: ```js import { AuthContext as fromApp } from './context/auth'; import { AuthContext as fromLib } from 'some-lib/auth'; console.log(fromApp === fromLib); // false => two objects, mystery solved ``` If you cannot import both, log the object itself from the provider component and from the consuming component and compare the two references in the console — identical source with different identity is the signature. React DevTools helps from the other direction: inspect the consumer and look at the context it is reading, and inspect the provider; a provider that no consumer is bound to, sitting right above consumers that show default values, is the same finding by a different route. A useful sanity check before any of this: confirm the provider really is an ancestor in the **React** tree, not merely nearby in the DOM or rendered as a sibling. Ruling that out first stops you chasing a bundling ghost when the tree shape is simply wrong. ## Fixing it The fix belongs at the module level, not in the component. Ensure a single instance of the module that calls `createContext`: deduplicate the offending dependency so one copy is installed, resolve the package to a single build, or make the context module the single owned source that both sides import from the same path. For a library, publishing React as a peer dependency and not bundling it is the standing rule. What you must **not** do is paper over it — passing the value as a prop past the boundary, or creating a second provider for the second context object, leaves two sources of truth that will diverge. ## Interview framing The grader is listening for the leap from a symptom to the right model: context is matched by object identity, therefore the default means "no provider for *this object*", therefore the question is which object each side is holding. Naming a plausible duplication mechanism and a concrete `===` check is what separates a candidate who has debugged this from one who has only read about context.