[Persistence] Errors in persistence (after creating/modifying objects) should be visible to user about openmct HOT 17 CLOSED

Assigning to Victor, he will file a separate issue to design notifications around async operations and progress indicators, and he will implement this handling in different cases.

from openmct.

This need some UX design - Charles created issue #154.

from openmct.

Want to use infrastructure from #155 if possible, but that's a nice-to-have

from openmct.

Per tagup on 12/1/2015, narrow this down to complete in current sprint.

In persistence capability:

• handle false return from persistence service as promise rejection.
• throw global notification.

This leaves it open to implement per-action rejections at the persistence service so we have more information about errors and can provide errors that are more relevant to context. #58.

from openmct.

I require a little clarification here. So the persistence capability is (for now) going to produce a blocking message indicating that there was an error, and reject the promise? Or should it be a non-blocking notification?

At some later date this will be finessed by removing the global error message, and implementing function-specific error messages.

from openmct.

is blocking vs unblocking something that is non-trivial to change? Doesn't seem like it matters and ultimately it should be a tiny change to switch blocking to unblocking.

from openmct.

Yeah it's totally trivial. Just wanted to confirm the approach, and that it's in the persistence capability that I'll make the change, and not further downstream.

from openmct.

Yep, persistence capability is the right place for this (insofar as it covers a broad range of cases.)

I believe we said blocking on the call earlier, so let's go with that for now since it will be easy to change later.

from openmct.

So this ended up being a little more involved than I initially thought.

The persistence queue bundle has reasonably comprehensive persistence error reporting already. This takes the form of a blocking dialog that appears in most persistence failure modes (that I tried anyway), and not just in the case of conflicts. This actually appears after the PersistenceCapability is invoked so would result in duplication of dialogs if I were to implement a blocking dialog at that point. The existing functionality also provides the option to overwrite if the persistence error is due to a conflict in the remote store. As such, I'm reluctant at this point to remove this functionality. I also don't want to stick another blocking dialog in front of it. Moreover the CopyService has its own error handling using the DialogService.

As such, the approach I've gone for in the meantime is to implement failure messages as non-blocking notifications. This works alongside the existing blocking persistence notifications without being intrusive. It also provides error notification if queueing is disabled. If this approach sounds reasonable I'll add some unit tests and file a PR.

Longer term, there needs to be some reconciliation between the different approaches. If nothing else, the queueing errors need to look consistent with errors elsewhere. One option might be to integrate the newer notification options into the PersistenceFailureHandler. Another option is actually to refactor the PersistenceFailureHandler out of the queue bundle, and make it responsible for more generic persistence error handling, offering options such as overwrite, retry, etc.

from openmct.

I think we have an alternate issue for removing the persistence queue; I think the persistence service doing anything more than resolve/reject is out of scope. The service shouldn't have UI bindings.

I would expect individual operations to handle persistence failures differently as the failure of each user-action could potentially have different UX requirements, and each failure may require different clean up in the case of batch operations.

At baseline: implement support for individual failures (e.g. copy fail, save fail, link fail) instead of a global persistence failure handler. Once that is done, if we see a common pattern, then we support that, but from experience there isn't a global pattern that provides good UX without significant effort.

from openmct.

I agree that the persistence errors should be bubbled up so that context appropriate handling can take place. The generic persistence error handler is proposed as an alternative that integrates with and extends the current persistence queue error handling.

There may be a case for generic handling of certain types of errors, or for abstracting details of the underlying persistence store. If we want to give users the option to overwrite or discard conflicting modifications for example, implementing this separately for copy, save, link, etc. doesn't make much sense. But in any case, any generic handling should happen higher in the stack.

from openmct.

Have created #373 for addressing refactoring and reconciliation of differing approaches to persistence error notification.

from openmct.

Testathon 20151207 - So there is a series of errors that appear in the bottom bar, but to my mind, they are a bit too subtle (small and dark at the bottom instead of big and bright in the center). It still allows me to proceed around the tool even though the network is disconnected, and when I come back, that item still appears. I'm not sure what behaviour would be enough to really make me notice, and know that the work I've done is not going to survive me closing the browser, but this doesn't seem to be enough.

from openmct.

I believe that switching to a blocking dialog should be fairly easy here. Still not ideal UX, but ensures the necessary information gets conveyed; we can improve iteratively from there.

In nominal circumstances we don't expect to see these errors often (on console, connection to the server should be reliable; remotely, don't expect to create much) so this kind of messaging should not be practically disruptive

from openmct.

Testathon 20151207: Disconnected computer, tried to create an object. Notification appears, but once minimized overlay cannot be displayed while the system is disconnected. #383 filed to cover a fix to this behavior.

from openmct.

Quick fix for dialog not being available - prefetch all templates (e.g. during initialization of mct-include and mct-representation directives)

May need to prefetch earlier if this will compete with search indexing etc

from openmct.

Resolved by #388

from openmct.