@ti-engine/core 1.10.0 → 1.11.1

package/CHANGELOG.md

@@ -2,6 +2,75 @@
 
 This document contains the list of changes made to the framework. The format is based on the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
 
+## Version 1.11.1
+
+License change only — no functional code changed.
+
+* chore(license): relicense package from `GPL-3.0-or-later` to `Apache-2.0`. See `LICENSE` and `NOTICE`
+* docs(license): update every source file's license header to the Apache-2.0 notice
+
+## Version 1.11.0
+
+`decycle` silently lost a key named `__proto__` and corrupted the surrounding document. It built its replica as `{}`
+and copied keys in by bracket assignment, so that one name hit the inherited prototype setter instead of becoming an
+own property: the key vanished and its value became the replica's prototype, which `stringifyJSON` then flattened
+back in as unrelated top-level keys. An object with an own `__proto__` key holding `{ hello: 1 }` alongside an `ada`
+key serialized to `{"ada":{…},"hello":1}` — the key gone and `hello` promoted to a sibling. (Note the input cannot be
+written as an object literal: in `{ __proto__: x }` that name is a prototype setter, not a key, even quoted. Only a
+computed key or an assignment onto `Object.create( null )` produces the property this bug needed.)
+
+This reached Redis: `cache.setJSON` serializes with `stringifyJSON`, so any caller storing such a key lost it against
+a real cache. `decycle` also runs on the message-exchange integrity-hash path, and over an exception's `data` whenever
+`raise` is given one. No test caught it because web-framework's in-memory cache double clones with
+`JSON.parse( JSON.stringify( … ) )` and never reaches `stringifyJSON`.
+
+**This is a minor rather than a patch release because it requires a consumer code change** — see the note below. The
+fix is a bug fix, but the replica's prototype is part of the observable contract.
+
+* fix(tools): build `decycle`'s object replica with `Object.create( null )`, so a key named `__proto__` is an ordinary
+  own key with no setter to hit. Verified against both consumers of the output — `_.isPlainObject` accepts a
+  null-prototype object, so `decomposeJSON` (message hashing) and `_.toPlainObject` (serialization) are unaffected
+* fix(tools): the same guard in `errorToJSON`, which copied an error's own property names with the identical pattern
+* fix(cache)!: `Cache.getValues( keys, prefix )` resolved **every key to `null`**, whatever Redis returned. Its ternary
+  inspected `results`, the accumulator being built, instead of `result`, the per-key `[ error, value ]` entry — and
+  `{}.length` is `undefined`, so the comparison was always false. The single-key `getValue()` had the correct form; the
+  two expressions were near-identical and one drifted. No first-party caller existed, which is why nothing caught it.
+  The per-entry decode and the key mapping are now two shared module-level functions (`decodeCommandValue`,
+  `mapCommandValues`, exported for testing) rather than duplicated inline expressions, so the drift cannot recur. The
+  mapping iterates the requested keys rather than the raw results, so a short response yields an entry per requested
+  key instead of silently omitting some, and its accumulator is a null-prototype object for the same reason as above —
+  cache keys come from the caller, and one named `__proto__` would otherwise repoint the map's prototype. Marked
+  breaking only because the returned map now has a null prototype (see the note below); the value behaviour is a
+  straight bug fix
+* test(tools): pin the regression, the cycle handling it must not break, the `decomposeJSON` and `retrocycle` paths,
+  and the fact that a key named `constructor` was **never** affected — it is an ordinary writable data property, so
+  bracket assignment always shadowed it correctly, and the fix's shape should not imply otherwise
+* build(release): bump package version from `1.10.0` to `1.11.0`
+
+`retrocycle` was checked and is not affected: it mutates objects that already came through `JSON.parse`, which creates
+`__proto__` as an own data property, and assignment to an existing own property shadows the inherited setter.
+
+**Breaking for consumers who touch the returned object directly.** The objects returned by `decycle`, by `errorToJSON`
+for an `Error`, and by `Cache.getValues` now have a **null prototype**, so they inherit nothing from `Object.prototype`. Passing
+them to `JSON.stringify`, lodash, or `decomposeJSON` is unaffected; the following are not, and the first two throw
+rather than merely behaving differently:
+
+| Expression on the returned object | Before | Now |
+|---|---|---|
+| `` `${ result }` ``, `String( result )`, `result + ""` | `"[object Object]"` | **`TypeError: Cannot convert object to primitive value`** |
+| `result.toString()`, `result.valueOf()` | works | **`TypeError`** |
+| `result.hasOwnProperty( key )` | works | **`TypeError`** — use `Object.prototype.hasOwnProperty.call( result, key )` |
+| `result instanceof Object` | `true` | `false` |
+| `result.constructor` | `Object` | `undefined` |
+
+The likeliest way to hit this is interpolating an `errorToJSON` result straight into a log line. Wrap such a value in
+`_.cloneDeep( … )` — which normalizes the prototype back — or serialize it explicitly. No call site in this monorepo
+does any of the above; every first-party `hasOwnProperty` use is already the `Object.prototype.…call` form.
+
+**Mixed-version note:** for the rare message carrying a literal `__proto__` key, an old sender and an upgraded receiver
+compute different `createMessageHash` values, so the receiver raises `E_SEC_MESSAGE_TAMPERING_DETECTED`. Such messages
+were already being corrupted in transit, so this surfaces a pre-existing problem rather than creating one.
+
 ## Version 1.10.0
 
 * feat(localization): `getLabel( label, language, fallback )` takes an optional third argument returned when the key