Debugger - Cannot read property 'typeClass' of undefined

[kevinbluer]

Still working on consistent (or as close as possible) repro steps. In the interim, a few excerpts from 2 different stack traces...

TypeError: Cannot read property 'typeClass' of undefined
    at tieWithTable (/Users/bluer/Developer/vscode-ext/node_modules/@truffle/debugger/node_modules/@truffle/codec/lib/format/utils/circularity.ts:18:23)
    at tieWithTable (/Users/bluer/Developer/vscode-ext/node_modules/@truffle/debugger/node_modules/@truffle/codec/lib/format/utils/circularity.ts:30:31)
    at Object.tie (/Users/bluer/Developer/vscode-ext/node_modules/@truffle/debugger/node_modules/@truffle/codec/lib/format/utils/circularity.ts:7:10)
    at Object.decode [as default] (/Users/bluer/Developer/vscode-ext/node_modules/@truffle/debugger/node_modules/@truffle/codec/lib/decode.ts:24:35)
    at decode.next (<anonymous>)

TypeError: Cannot read properties of undefined (reading 'variables')
rejected promise not handled within 1 second: TypeError: Cannot read properties of undefined (reading 'variables')
stack trace: TypeError: Cannot read properties of undefined (reading 'variables')
    at map (/Users/tyler/projects/truffle/packages/debugger/lib/data/selectors/index.js:676:54)
    at Array.map (<anonymous>)
    at map (/Users/tyler/projects/truffle/packages/debugger/lib/data/selectors/index.js:675:54)
    at Array.map (<anonymous>)
    at /Users/tyler/projects/truffle/packages/debugger/lib/data/selectors/index.js:658:37
    at /Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/index.js:87:25
    at memoized (/Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/defaultMemoize.js:135:20)
    at /Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/index.js:101:40
    at Function.memoized [as _] (/Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/defaultMemoize.js:135:20)
    at /Users/bluer/Developer/vscode-ext/node_modules/reselect-tree/lib/index.js:85:1
    at /Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/index.js:97:37
    at Function.memoized [as _] (/Users/bluer/Developer/vscode-ext/node_modules/reselect/lib/defaultMemoize.js:135:20)
    at /Users/bluer/Developer/vscode-ext/node_modules/reselect-tree/lib/index.js:85:1

[kevinbluer]

@michaeljohnbennett getting this consistently now when attempting to debug TruffleDAO.propose(). Noticed we're somewhat behind with our @truffle/codec version (v0.11.22 vs v0.12.5) so going to try bumping that.

[kevinbluer]

Bumped @truffle/codec although no joy 😓

[gnidan]

cc @haltman-at

[michaeljohnbennett]

as raised in the chat channel for truffle. This looks like an issue with the tieWithTable in codec not always being passed in the correct Result object but what appears to be prototype values/functions when passed in an Array of address objects.

Codec needs fixed or the saga code to handle this case better before we can close this.

[michaeljohnbennett]

I’ve been debugging/researching an interesting issue we have in the VSCode extension when debugging some transactions from the truffle-dao box. These are non trivial contracts (a few OZ imports etc) and when I do the forTX call with the hash for any of the migrations/commands I was getting some timeouts/errors which appeared to be the Web3Provider not being able to connect to the RPC client. This wasn’t correct because the same Web3Provider was talking to the client moments before in VSCode to get the transaction hash lists. It turns out there is something strange happening in the codec tieWithTable code in circularity.ts. It seems to think it will always get an untied: Format.Values.Result object. But for these transactions it's not.

Debugging the same TX on the command line works without a hitch. For us it was bombing out. This might be due to different config we pass in to the forTX call but interestingly when I added in defensive coding blocks to the method and debug it looks like the tieWithTable function is being passed in functions/objects that are definitely not Result objects. I have no real idea where its coming from because of all the yields and async stuff makes the actual root cause very hard to ascertain.

so it seems a typeClass of array is being sent in. And somehow after that it's going a bit crazy. It looks like it's taking all the prototype elements from that and then trying to call them through this code is my first guess.

It looks like this address array is the culprit

[haltman-at]

OK I've merged trufflesuite/truffle#5005 to deal with this!

[kevinbluer]

FWIW i'm still appearing to get the issue despite the fix 😢 To confirm in case I'm missing something, I've bumped @truffle/codec to 0.12.7 and re-running the following steps (including for reference / broader reproducibility):

• truffle unbox dao
• truffle migrate
• truffle exec scripts/propose.js (which will error)
• Debug the txn from the VSCode command palette:

For reference it works fine off the CLI (truffle debug 0xad41f4...).

[haltman-at]

When you say you're still getting the issue, what exactly do you mean?

[michaeljohnbennett]

From my testing as well prior to merge of your PR @haltman-at those code blocks would pass when debugging some of the time. It looks like something else down the stack/elsewhere in the process is crashing/failing and we get back the general error from the redux store that it cannot connect to the RPC client which seems to be the general error we see.

More investigation will need to be done on our side and any pointers on how to get more meaningful debug output from code and debugger would be appreciated, especially inside the sagas code.

[kevinbluer]

When attempting to debug (via the following step included above), I get above Cannot read property 'typeClass' of undefined in my debug console

[haltman-at]

Any stacktrace or anything?

[kevinbluer]

Was just doing some digging into this (and about to reply to your above question @haltman-at) when I noticed session.ready() wasn't actually being called. Just added as a temp fix and it seems to be a lot more consistent. It also seems to correlate with "sporadicalness" of the issue(s) we've been experience. Any take @haltman-at?

[haltman-at]

session.ready has been a dummy for quite some time. It isn't necessary anymore, not unless you're using a really old debugger version...