Parley Bug: Undo Stack Issues During Bulk Operations
Hey guys, let's dive into a frustrating bug I found in Parley related to its undo stack during bulk operations. This issue, discovered during testing, causes a discrepancy in how the undo stack handles multiple actions, leading to potential data loss and user frustration. This article will break down the problem, the steps to reproduce it, and the potential impact it has on users. So, buckle up!
The Bug: Undo Stack Not Working as Expected
During testing, specifically Test 6 (Undo Stack Limit), the undo stack in Parley wasn't behaving as expected. The core of the problem lies in how the undo stack manages operations when a bunch of nodes are added in quick succession. After adding 55 nodes (we'll explain how in a sec), undoing those actions resulted in a lower node count than we anticipated. This suggests that some undo states are either not being created correctly or, even worse, are being lost along the way. That's a major bummer, because the undo feature is super important for users to correct any mistakes.
This bug was unearthed while testing Issue #28, which deals with undo/redo system issues. It's also linked to other problems, like Issue #72, which affects the undo/redo functionality. Understanding this bug is crucial for anyone using Parley to handle large projects where undoing multiple actions is a necessity. Now, let's look at the steps to reproduce this annoying bug.
Steps to Reproduce the Parley Undo Bug
Alright, so here's how you can replicate this bug in Parley. It's a fairly simple process, and here are the steps you need to follow: First, fire up Parley, and either open a new, empty dialog or a small one. It doesn't really matter. The key is to start with a blank canvas or something with very few elements. The next move is to add 55 nodes one at a time. The quickest way to do this is to use the "Duplicate" function, typically bound to Ctrl+D. Keep hitting that combo until you have 55 nodes. Now, the fun part begins: press Ctrl+Z repeatedly to undo the actions. That's your standard undo shortcut, which should undo each node addition. Next up, you need to count how many undo operations actually work. Does it go back to where you expect? Keep an eye on the number of nodes left after each undo to see if it matches the expected count. And last but not least, compare the final node count with the result you're expecting.
If the actual node count after undoing isn't what you anticipated, you've successfully reproduced the bug. This is where the discrepancy occurs. This is the core issue of this bug: the undo stack isn't correctly tracking all the actions, and some are either missing or being dropped.
Expected vs. Actual Behavior: The Discrepancy
So, what's supposed to happen? And what actually happens? Let's break it down to understand the problem. The expected behavior is pretty straightforward. First off, the undo stack limit is configured to handle around 50 operations. This means Parley should only store the last 50 actions for undoing. Once you add 55 nodes, you should be able to undo 50 times. The oldest 5 operations should be discarded because of the FIFO (First-In, First-Out) method. That means the oldest action is the first to be discarded and the newest action is the last. After undoing 50 times, you should be left with 5 nodes. The final state should show 5 nodes remaining (55 initial nodes - 50 undos = 5 nodes).
However, here's what actually happens. The undo count is lower than expected. After undoing, the node count is incorrect. Instead of the expected 5 nodes, you'll likely see more. This suggests that either the undo states for all operations aren't being created, or the states are being lost. It's a silent failure. There is no warning. This is a critical issue that compromises the reliability of Parley's undo function, especially during bulk edits.
The Impact of the Undo Bug
This bug is no small potatoes, my friends. Its impact is pretty significant, and here’s why: the severity of this issue is considered High. The most concerning aspect is the data integrity. The undo operations become unreliable. Users can't trust the undo feature during bulk edits, which is a massive headache. Imagine spending a bunch of time building something and then realizing you can't undo a mistake. That's frustrating and can lead to lost work. There is also a silent failure. The user has no indication that the undo states are missing. Parley doesn't tell you, "Hey, some of your actions weren't saved for undo." The absence of clear feedback adds to the confusion.
This lack of trust in the undo function can hinder productivity and potentially lead to data loss. This bug can make users second-guess their actions, leading to a less-than-ideal user experience. The need for an automated test is crucial to prevent this kind of problem in the future.
Testing Evidence and Details
Let’s look at some of the testing that revealed this bug. The issue was found during testing, specifically Test 6, within Issue_28_Testing_Checklist.md. The result of this test was a FAIL. The tester's notes clearly point out the problem: "I did not get the count I was expecting and when I ctrl z'd I should have had more nodes than I had. do an automated test for this." This confirms the discrepancy between the expected and actual node counts after undo operations. This test was done on the shady.dlg test file, on November 8, 2025, using commit 8cdc835 (fix/undo-corruption-28). The session log is 15MB log (Session_20251108_153628). This log contains valuable information that could help pinpoint the issue’s root cause. It is really important to keep these test results and environments details because it offers a clear picture of when and where the bug was discovered. This helps understand the context and helps other developers to understand the issue.
Related Issues & Areas for Investigation
This bug is linked to other issues. The bug has some friends, and knowing them can provide more insights:
- #28: Undo/Redo corruption fixes. This issue deals with general problems related to the undo/redo functionality.
- #72: Redo breaks undo stack. This issue explains that the redo operation is causing problems with the undo stack.
- #73: Double Ctrl+Z required. This is another bug that means you have to press Ctrl+Z twice to make it work.
To find the root cause and squash this bug, we need to dig deeper. Here's a checklist of what needs to be investigated:
- Verify the undo stack limit configuration (default: 50?)
- Check if all node additions create undo states.
- Verify FIFO eviction of oldest states.
- Test with different operation types (add vs duplicate vs paste).
- Profile undo state creation during rapid operations.
- Check for race conditions during bulk operations.
The Need for an Automated Test
To ensure this bug is fixed and doesn't resurface, an automated test is absolutely essential. An automated test will give us a repeatable way to check if the undo stack works correctly. This test should verify the following:
- The undo stack respects the configured limit. It should only store the set number of operations.
- All operations create undo states. Every action should be recorded for potential undoing.
- FIFO eviction works correctly. The oldest actions should be discarded first.
- The undo count matches the expected value.
- The final state matches the expected node count.
The automated test needs to be able to programmatically add 55 nodes, count the undo states, execute all available undos, and verify that the final node count is exactly 5. This kind of test will give us the peace of mind that the undo function is working correctly, even during rapid bulk operations. An automated test is critical for preventing future regressions and ensuring the reliability of the undo functionality in Parley. And that's all, folks!