In JavaScript, an assignment such as `obj.total = 5` appears to do nothing — reading `obj.total` afterwards still gives the old value and no error is reported. What conditions on the prototype chain cause this, and how would you confirm which one applies?

## Why an assignment can be a no-op The common summary "reads walk the chain, writes do not" is true about *where the value lands*, but not about what the write consults. `obj.total = 5` invokes [[Set]] with `obj` as the receiver, and before creating an own property the engine looks for an existing `total` along the chain. What it finds decides the outcome. ## Case 1: an inherited getter-only accessor ```js const proto = { get total() { return 0; } }; const obj = Object.create(proto); obj.total = 5; obj.total; // 0 Object.hasOwn(obj, 'total'); // false ``` An accessor whose descriptor has `get` but no `set` cannot receive a value, and the specification does not fall back to creating an own property. In sloppy mode the assignment is discarded silently. In strict mode it throws: ```js 'use strict'; obj.total = 5; // TypeError: Cannot set property total ``` Since ES modules and class bodies are always strict, the same code often throws in one file and stays silent in another — which is exactly why the bug survives so long in scripts. ## Case 2: an inherited non-writable data property ```js const proto = {}; Object.defineProperty(proto, 'total', { value: 0, writable: false }); const obj = Object.create(proto); obj.total = 5; // ignored (sloppy) / TypeError (strict) ``` A non-writable property on the chain blocks assignment on every object below it. This surprises people who expect the inherited property merely to be shadowed, and it is one reason `Object.freeze(proto)` has effects reaching well beyond the frozen object itself: freezing makes every data property non-writable, so instances below can no longer assign those names. ## Case 3: an inherited setter that absorbs the value ```js const proto = { set total(v) { /* validation that rejects odd inputs */ }, get total() { return 0; } }; const obj = Object.create(proto); obj.total = 5; Object.hasOwn(obj, 'total'); // false — no own property created ``` Here the write did something: the setter ran, with `this` bound to `obj`, not to the prototype. If the setter stores nothing, validates and drops the value, or writes to a differently named backing field, the observable result is again "the assignment did nothing". No error is thrown in any mode, because the write was accepted. ## The diagnosis sequence 1. **Did the write land?** `Object.hasOwn(obj, 'total')`. If `true`, the write succeeded and your problem is elsewhere. If `false`, the chain intervened. 2. **Who owns the name?** Walk it: ```js let o = obj; while (o && !Object.hasOwn(o, 'total')) o = Object.getPrototypeOf(o); Object.getOwnPropertyDescriptor(o, 'total'); ``` 3. **Read the descriptor.** `{ get, set: undefined }` is case 1. `{ writable: false }` is case 2. `{ get, set }` with a function is case 3 — read the setter's body. 4. **Re-run in strict mode.** Under strict mode cases 1 and 2 throw a `TypeError` with the property name, turning a silent bug into a stack trace. This is a strong argument for modules and `'use strict'` in any remaining scripts. ## The escape hatch, and when it is wrong `Object.defineProperty(obj, 'total', { value: 5, writable: true, enumerable: true, configurable: true })` performs [[DefineOwnProperty]] on the target directly. It never walks the chain, never triggers an inherited setter, and is not blocked by a non-writable inherited property. `Reflect.defineProperty` is the same operation returning a boolean instead of throwing. Be deliberate about using it. If the prototype exposes a getter-only property or a setter that validates, that is usually an intentional contract, and forcing an own property past it breaks the invariant the author was protecting. Use it when you genuinely own both sides — for instance when a base object was frozen for safety and a derived object legitimately needs its own value. Note also that anything built on ordinary assignment behaves the same way: `Object.assign(target, source)` and `Reflect.set(target, key, value)` both use [[Set]], so they too can be diverted by an inherited setter or blocked by a non-writable inherited property. Copying with `Object.assign` is therefore not a reliable way to force values onto an object whose prototype constrains them.