-
Notifications
You must be signed in to change notification settings - Fork 323
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
Don't cancel pending visualization's upserts #8853
Don't cancel pending visualization's upserts #8853
Conversation
Uniqueness check of `UpsertVisualizationJob` only involved expressionId. Apparently now GUI sends mutliple visualizations for the same expressions and expects all of them to exist. Since previously we would cancel duplicate jobs, this was problematic. This change makes sure that uniqueness also takes into account visualization id. Fixed a few logs that were not passing arguments properly.
Added a problematic case where visualization upserts would get cancelled because uniqueness took into account only expression id but not visualization id. The test is a bit tricky to setup because it relies on a) multiple attach visualization requests b) background job trigger cleaning up duplicate jobs (here triggered via edit)
...ument-common/src/main/scala/org/enso/interpreter/instrument/job/UpsertVisualizationJob.scala
Show resolved
Hide resolved
|
||
attachVisualizationResponses.filter( | ||
_.payload.isInstanceOf[Api.VisualizationAttached] | ||
) shouldEqual List( |
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.
This test would previously fail.
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.
Mostly process oriented approval. I didn't try to understand the changes in RuntimeVisualizationsTest
.
...ument-common/src/main/scala/org/enso/interpreter/instrument/job/UpsertVisualizationJob.scala
Show resolved
Hide resolved
Based on the last failures I basically think that |
`runtime-instrument-common` depends on `runtime` but `runtime/test` depends indirectly on `runtime-instrument-commont`. We somehow managed to deal with it for modules, but separate compilation breaks everything in CI. This workaround will make sure that CI passes :fingers-crossed:.
The circular dependency between `runtime` and `runtime-instrument-common` is the root of all evil. There is no way around until now, at the cost of some duplication. Should fix issues in incremental compilation when changing between branches.
Working on a fix in a separate PR.
Pull Request Description
Uniqueness check of
UpsertVisualizationJob
only involved expressionId. Apparently now GUI sends mutliple visualizations for the same expressions and expects all of them to exist. Since previously we would cancel duplicate jobs, this was problematic.This change makes sure that uniqueness also takes into account visualization id. Fixed a few logs that were not passing arguments properly.
Closes #8801
Important Notes
I have not noticed any more problems with loading visualizations so the issue appears to be resolved with this change.
Added a unit test case that would previously fail due to cancellation of a job that upserts visualization.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.