immerjs / immer

Create the next immutable state by mutating the current one

Home Page:https://immerjs.github.io/immer/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`produce` leaks proxy objects when symbols are present

dhmk083 opened this issue ยท comments

๐Ÿ› Bug Report

When you use produce on an object which contains a symbol property which is an object, it leaks Proxy object into returned value.

Link to repro

https://codesandbox.io/p/sandbox/suspicious-sanne-2ypqwt

To Reproduce

  1. Get an object with symbol:
const sym = Symbol()

let state = {
  id: 1,
  [sym]: {} // must be an object
}
  1. Use it with produce and read state[sym] value inside draft function. In returned value state[sym] object will be a revoked proxy instead of plain object.

  2. Use it with produce again. Now an error will be thrown because state[sym] is corrupted.

TypeError
Cannot perform 'getPrototypeOf' on a proxy that has been revoked

Observed behavior

Proxy object is leaking out of produce function.

Expected behavior

Plain object should be returned instead.

Environment

The bug appears since 10.0.0 version. It works fine in 9.0.21 version.

No, still error.

I encountered the same issue. Reverting to version 9.0.21 resolved the problem for me as well.

This was changed here: 452a508#diff-4ade25325a6cd7d1cca619364c84d19bfa47e6939a2c1b38d065767255b8f86eR66

However, based on the commit messages, I'm not sure why the change was made.

Hello! Had the same issue, objects nested on symbols are automatically revoked.

Fyi: Sets seem to work, it seems to only affect objects.

Is this a necessary change for 10.0.x or can it be reverted? @mweststrate

Likely same issue as #1096. Will investigate when I can carve out a sliver of time. If someone is willing to submit a PR with unit test(s), that will already be quite helpful!

#1105 should fix the handling of Proxy properties. When drafted, they are now finalized correctly. Let me know if it isn't solved by immer@10.0.4

10.0.4 fixes this issue for us, although it introduced another issue; see #1106.