wallaby constantly getting out of sync

[aaronjensen]

Wallaby Console: Atom plugin v1.0.7
wallaby.js:70 Wallaby Console: Core v1.0.112

Randomly wallaby will be working against old code, usually code that is part way through my typing. I type fairly quickly, so it seems like it's using a leading throttle instead of a debounce somewhere, if you know what I mean.

[ArtemGovorov]

I tried fast typing/code pasting, but I can't yet catch it. Do you see the issue happening when you're editing different tests/source files or just in some of them (like async tests)? Did you notice any specific code editing patterns that lead to issue more frequently than others, such as inserting line breaks vs just single line editing? How frequently does it happen?

From your previous bug reports I'm assuming you're using webpack + babel stack when hitting the issue? Could you please try to see if you can hit it while editing code/specs in the https://github.com/aaronjensen/wallaby-line-number-repro repo?

What's the wallaby status indicator state when you hit the issue? Is it spinning or is 'red'?

If you set debug: true in your config and open wallaby log in the dev tools, what's the last message when you hit the issue? Is it Test run result processed and sent to IDE? Could you please also scroll the log up a bit (until you see the Wallaby Console: Runtime error: ReferenceError: Can't find variable: stat message) and see if there're log entries after it that are saying File changed in editor: ..., File ... changes saved, store ts: ..., change ts: ..., `Test run started; run priority: 2?

[ArtemGovorov]

Oh, one more question - was it happening previously as well or started just recently?

[aaronjensen]

I'll see if I can repro it when I can. I've definitely seen it before, but today on my work machine it happened about 3 or 4 times in a short period of time.

[ArtemGovorov]

Thanks Aaron. Even if it doesn't reproduce reliably, only sometimes, but is happening on that repository, still please let me know where and when you've been observing it and I'll keep digging.

[aaronjensen]

While trying to debug a "Parse error" I'm getting, I added a console.log to a file I thought was causing the parse error. Upon doing so, I saw something I saw once before which is related to this getting out of sync. Sometimes, when I type something, it attempts to parse a version that includes the thing I typed twice. In the below picture I only typed:

console.log("DJJDJD");

but it doubled up the string:

[ArtemGovorov]

Wow, never seen anything like this in wallaby! Tried adding a similar Parse error and reproducing the issue on https://github.com/aaronjensen/wallaby-line-number-repro repo, but no luck, may be specific to the (structure) of the code/tests that you're editing or maybe I'm missing some other steps required to reproduce it. It'd be so awesome to catch and fix all those issues, would be very interested to see what is causing this specific one.

[aaronjensen]

I've only seen it two or three times, it's a strange one. I definitely can't repro it consistently.

[ArtemGovorov]

Quick question - do you save files frequently? Perhaps you've noticed some correlation between saving a file and then observing any of the issues mentioned above? Or it happens when you type even before you save a file?

[aaronjensen]

I wouldn't say I save files too frequently, but it depends on what I'm doing. In this case, I was adding a console.log for something I wanted to see in the browser I think so I probably hit save right afterwards. I sometimes try saving a file after I see one of the issues mentioned but it never seems to resolve it. Changing the file doesn't always resolve it either. I usually need to restart wallaby.

[ArtemGovorov]

Ok, thanks to lots of hints I've got from you, I reproduced and fixed it (found the same reason for both old and duplicated code). Please try core 1.0.117, and let me know if you spot the issue again.

[aaronjensen]

awesome. Mind if I ask what the issue was? It was a particularly weird one :smile:

[ArtemGovorov]

@aaronjensen So wallaby creates diffs (patches) with a previous file version when a file is changed (to later apply the patch to its cached version). Unlike IntelliJ and Visual Studio, that have built-in file change notification infrastructure, in case of Atom, wallaby receives the information about file changes from 2 places - right from the editor when you change some code and from watching the project folder with an FS watcher. The issue was editor changes were handled synchronously, while FS watcher sourced events (such as file save), were handled asynchronously.

So when you change your code and hit save right after it, there was a case where FS watcher notifies about the file change, wallaby would remember the file content before the change, and start reading the file. While it's reading, the editor change event (that is debounced so comes after) would arrive, get the file content before the change, produce the patch and send it to further. Then when file reading is finished, it would produce one more patch and also send it. That's where we were getting the duplicated code change from. Sometimes full content of the file is sent, not just a patch, and that's where where we were getting the older file version from.

[aaronjensen]

ah, good find! Thanks for the fixes. Things have seemed more stable today.

[ArtemGovorov]

Thanks, there're still unresolved issue to be addressed with the mass file changes while wallaby is running (when you reset a few commits back and forth), but that one is different from the one that's fixed.