-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: an eval&undo/redo "lost ID" bug #1086
Conversation
Previously `AppTestM` transformed `TestM`, thus it had both an `App` state (recall, an `App` contains some fresh `ID` and `NameCounter` state) and also a separate `ID`/`NameCounter` state via `TestM`. Thus, some things use one set of counters, and some the other. In particular, `handleRedoRequest` works via `runEditAppM` which uses the `App`'s counters, but `handleEditRequest` uses the `TestM`'s counters. This only happened in tests, and not in the actual service. This commit ensures that tests are closer to the real service by removing the `TestM` layer, ensuring that we always use the `App`'s counter. (This is needed to tickle some long-standing bugs involving "lost IDs" in the undo/redo system.) Signed-off-by: Ben Price <[email protected]>
The refactoring in the previous commit left this argument unused. Signed-off-by: Ben Price <[email protected]>
Signed-off-by: Ben Price <[email protected]>
f6cc38a
to
f9415f0
Compare
f9415f0
to
24d18a3
Compare
This is in preparation for moving Eval into `MonadQueryApp` rather than `MonadEditApp`. Signed-off-by: Ben Price <[email protected]>
This makes it consistent with `liftQueryAppM`. Signed-off-by: Ben Price <[email protected]>
This is in preparation for moving Eval into `MonadQueryApp`, as we need to know that `EvalFull` will never throw an error. Signed-off-by: Ben Price <[email protected]>
Prior to this, evaluation happened in `MonadEditApp`, and thus could change the fresh ID state embedded in the `App`. This can cause "lost ID" errors when interleaving actions, evaluations and undo/redos. Note that it is suspicious that `evalFull'` is still using `liftEditAppM` and generates a new ID via `gvar` -- this indeed leads to the same sort of issues, and will be dealt with in a subsequent commit. (The fact that this code will be changing very soon is why we have not gone to the effort of using `readerToState` here.) We have added a test showing that we have fixed this "lost ID" issue at the "richly-typed api" level. (Note that `evalFull'` is not part of this layer.) Signed-off-by: Ben Price <[email protected]>
24d18a3
to
29610a8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I seem to remember you saying earlier this week that you'd realised two issues that could lead to undo bugs (aside from version incompatibility). Did that refer to the last two commits here as separate issues, or is there a further fix needed?
The two issues were (a) the first commit and (b) the last two commits. The first (as mentioned in commit message) turned out not to be an issue in the deployed version (which explains why I could not manage to get a failure because of it). I am not aware of any other issues causing undo bugs after this PR. |
This finishes the work started in the previous commit, fixing the "simplified"/OpenAPI layer. Signed-off-by: Ben Price <[email protected]>
29610a8
to
b2e7c59
Compare
No description provided.