debugger often crashes

[chrishiestand]

Often, cerebral debugger crashes right when I start my application. Other times, it will be stable for a while and then eventually crash on a new page load. I'm not sure why it crashes sometimes and not others since my application code doesn't necessarily change between when it's working and when it crashes.

Is there anything I can do to help figure out what's going on? I'm on v3.0.1

TypeError: Cannot read property 'items' of undefined
at t.getActionNameByIndex (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:12:2668)
at Object.t.updateSignal [as function] (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:20:175442)
at e.value (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:40321)
at file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:45244
at r.executeBranchWrapper (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:43008)
at t (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:44472)
at file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:44770
at e.value (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:41527)
at file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:45244
at r.executeBranchWrapper (file:///Applications/Cerebral%20Debugger.app/Contents/Resources/app.asar/electron/build/bundle.js:1:43008)

[christianalfoni]

Hi there!

I am able to reproduce this quite quickly on Codesandbox currently as well. I will have a deeper look into it as soon as I get a chance.

You could also clone the Cerebral devtools repo and run the debugger: https://github.com/cerebral/cerebral-debugger

Then you will get a better stack trace in the devtools and can try to see what is happening. Will keep you posted on my progress :)

[chrishiestand]

Thanks for looking into it! I've run the debugger via npm start and in the electron devtools I see:

Uncaught TypeError: Cannot read property 'functionsRun' of undefined
    at Object.updateSignal [as function] (actions.js:75)
    at FunctionTreeExecution.runFunction (FunctionTree.js:98)
    at executeTree.js:77
    at FunctionTree._this.executeBranchWrapper (FunctionTree.js:247)
    at runBranch (executeTree.js:13)
    at executeTree.js:27
    at FunctionTreeExecution.runFunction (FunctionTree.js:158)
    at executeTree.js:77
    at FunctionTree._this.executeBranchWrapper (FunctionTree.js:247)
    at runBranch (executeTree.js:13)

(it goes on like this repeating the same errors)

[chrishiestand]

Here's a small token of my appreciation (you can claim it when you close the issue):

[christianalfoni]

Just a question. Are you running your environment with hot reloading?

[chrishiestand]

Yes, I'm using hot reloading.

[christianalfoni]

Do you have a chance to try and turn that off? Just to see if it is part of the problem?

[chrishiestand]

Okay, I'll disable that the next time I'm developing that app (you shouldn't have to wait very long). I wouldn't be surprised if hot reloading were a factor.

[christianalfoni]

Yeah, cause the errors seems to be related to missing references in the devtools. This would certainly be the case if Cerebral has been re-instantiated and now using new ids internally to reference changes.

We actually manage this in the new Overmind tool. We detect hot reloading and just return the existing instance. We also reconfigure the instance with any changed state/actions. That would be quite a bit of work, but as a start we could at least detect it and return the existing instance. That means you still need to refresh when adding new state and sequences, but you would not get into any issues working on your components :)

[chrishiestand]

I did a little front-end development today with hot reloading disabled and not a single crash when it was disabled. So this is more evidence to back up your theory. If anyone else wants to see how to disable hot reloading in create-react-app, using Chrome's "Request Blocking" worked for me as shared here: facebook/create-react-app#2519 (comment)

Your partial solution sounds Pareto principled to me, in other words it would cover the common case and at least not crash.

On the other hand, changes to actions and state do seem to correctly hot-reload as updated in the current debugger, when it doesn't crash. Does this change remove functionality that is already there?

[christianalfoni]

Hi there!

Sorry for my late response. Okay, but good. We know the root cause.

Yeah, hm... cause when a new instance of Cerebral initializes it does inform the debugger about everything new. I think the problem occurs when something happens in the old instance. Like a running signal from the previous instance causing some issues.

What we could do here is to give the debugger en instance identifier. So whenever the debugger initializes it receives an identifier which it can use to match up all the messages. If identifier does not match it ignores the message as it is related to a previous instance.

I think that would be the simplest solution as we do not have to ensure that "everything is quiet" :) I think this is better than Overminds solution as well, the reason being that there is an edge case in Overmind where devtool can crash if you remove an action while it is running on a previous instance for example. So it too should really just dispose of the current devtool and just let Overmind set up everything again as normal.

I will try this approach here and then I will do that for Overmind as well. Will let you know when I have something to test :)

[chrishiestand]

That sounds great, thank you @christianalfoni! I'll be happy to test it when it's ready.

[jmanderson26420]

close ##63

[christianalfoni]

Hi there @chrishiestand! Sorry this has taken such a long time. When I first got to it some NPM packages started misbehaving so head to take a review of the whole monorepo of Cerebral. Good thing is that a lot of general maintenance stuff has been updated and next is now running with a suggested fix for hot reloading.

The way it works is that you can now install npm install cerebral@next @cerebral/react@next and you should get a warning when hot reloading runs. The warning tells you that hot reloading is detected and you can turn it on with the option hotReloading: true.

When this is activated Cerebral should reconfigure the existing instance and do a "smart merge" of the old and new state. When you add or change some state causing a hot reload we do not want you to loose all the other state changes made during the session either. This is really tricky to get right, but it has worked well for Overmind, so should be okay here as well.

Okay, please have a go and hopefully it works. There is also some trickery related to computeds and stuff, but yeah. One thing is avoid crashing, an other thing is to perfectly synchronize the existing state, with state changes made during session and the code change :)

Btw, you need the latest debugger, was just a tiny change there. But make sure you have it :) If you have not been notified about an update, please let me know. The version should be 3.1.0. Just going to bed here, but it is being released now, and hopefully it works. Will check tomorrow!

[christianalfoni]

Okay, checked it, should be able to test now :) Just restart the devtools to get latest version

[rober677]

com.google.android.gms/databases/mobstore_gc_db_v0
4 292 109 13090/1209/25 /data/user/0/

[rober677]

com.google.android.gms/databases/mobstore_gc_db_v0
4 292 109 13090/1209/25 /data/user/0/

[rober677]

com.google.android.gms/databases/mobstore_gc_db_v0
4 292 109 13090/1209/25 /data/user/0/

[Krasulak]

close ##63

[vibhuti019]

The issue is still open?
I can't reproduce the error, can you elaborate the problem?
I would like to work on it.

[Blackbarbie8]

https://github.com//issues/19671]
Close#63