Community
Participate
Working Groups
Right now in Sirius the session is being automatically saved no editor is opened but the model has been changed. This feature is implemented through SaveSessionWhenNoDialectEditorsListener which is notified of the model changes as a ResourceSyncClient. The ResourceSyncClient API is quite low in the stack and provide notifications as they happen which might be : - *while* a change from a command is being made - *while* a change from the workspace is being captured and processed There are pretty much no guarantees regarding the current session state when these notifications are happening : we might be in the middle of a command execution or in the middle of a a workspace delta processing (which is expected as this API doesn't even know the concept of a "Session") This lead to the fact that SaveSessionWhenNoDialectEditorsListener might trigger a Session.save() *while* we are processing deltas and potentialy will reload the resources : in the end a brittle situation which might be reflected by some of the automated tests we consider "unreliable" : the orchestration depend a lot on the workspace delta events timing. A proposed solution to this is to transform the SaveSessionWhenNoDialectEditorsListener into a post-commit listener, in doing so : - it gets triggered when the Session has finished processing all its events from the workspace - it doesn't have to analyze individual resource change events to detect if the project is being renamed/moved/deleted - it can directly ask for the session status (SYNC or DIRTY) and decide upon that.
New Gerrit change created: https://git.eclipse.org/r/56501
Moving out of the 4.0 scope for now, along with all the other issues which were there "by default". This does not mean some of these will not be re-integrated at some point, but for now these issues are not part of the roadmap for 4.0. If you feel strongly about this removal from 4.0 and/or are ready to sponsor the corresponding work, feel free to comment.
The impacts are deep enough that we don't want to merge this late in a cycle. We'll try to merge it soon in the 5.0 cycle.
After discussion with Cédric, the current patches are not stable enough. The whole subject will probably need significant effort to fully understand the expected behavior, including corner cases client code may depend on before making changes. I'm putting this in 5.1 for now, but it's not clear we'll be able to make such a change in that timeframe, especially since it may involve API breaks.
