Clojurians Log v2

I sometimes run into issues where a state gets corrupted after start so stop throws

then I’m unable to restart as stop always fails

what’s the best way to avoid the cleanup-if-dirty phase?

I guess it’s covered by https://github.com/tolitius/mount/issues/63

@dm3: yea, there are options covered in this issue, but I would still like to find a solution and document it, since it is a valid concern. so ideas are very welcome

@dm3 there are also some related thoughts: https://github.com/tolitius/mount/issues/50

I don’t think Mount should be doing anything to manage failures in non-dev deployments

this can be built as convenience on top

however in development the states are sometimes clobbered which prevents them from being stopped

and currently there’s no way out

so I’d vote for something like reset

hm, does it even make sense to stop the stop action if something throws?

you can’t do much at this point

it might then make sense to make stop do best-effort of stopping everything that didn’t throw

I guess if we had something like reset - Stop all started states unconditionally and clear the internal Mount state

stop could keep its current behaviour

@tolitius what do you think?

> Stop all started states unconditionally and clear the internal Mount state yea, that is what I had in mind for something like (mount/reset :ignore-errors true) or just (mount/reset)

I’m still thinking what I’d like my system to do if one of the states fails to stop during shutdown

on start it’s easy - I don’t want the system to start up in a broken state

on stop it seems I’d like to stop as much as I can cleanly

I think this decision (what to do on a failed stop) is best left to "a developer", since use cases are different, but stop as much as I can could be a useful option

that’d probably be my default

resources that are still "connected" would be a problem though

yeah, you could still throw an “accumulated” exception once stop is done

but yea, "reset" would work ok for things that just throw the exception, but do not tie up any resources

yes

reset is for development

might make sense to not lose references to "states" in a bad "state" though..

what do you mean?

i.e. say you have a conn to db that threw on stop: i.e. could not disconnect

would still be good to return that reference after the internal mount references are "reset"

since something may still be possible at repl time: i.e. to force disconnect it

I’d think you would work with start/stop

then once stop failed you’d try reset

right, but it would mean a stale reference to something that is still connected

so after stop fails you can still do whatever is needed

you can, but you would not be able to reconnect

due to, say, a bound port

could you not do force disconnect after stop failed?

or is the state lost at that point?

right, if we are talking about a "reset": i.e. stop everything, even if it has failed, the original reference to conn would point to something like a NotStartedState vs. the actual problem state

so I am thinking it would make sense to still return (new) references to failed states

yeah, that’s fine by me because you have a chance to “force disconnect” after mount/stop failed

unless I misunderstand something

right, as long as you have a reference

when do you lose the reference?

is it lost after mount/stop fails?

no, it is lost if stop succeeds 🙂 but if we are to do a "reset" regardless, the reference would be lost

> it is lost if stop succeeds it would point to a DerefableState or NotStartedState after a successful call to "stop"

i.e. https://github.com/tolitius/mount/blob/master/src/mount/core.cljc#L98-L105

ok

yea, it's good food for thought. I'll start adding a "reset" this would prompt me to think more about it. thanks for bringing it up

what I’m trying to say is that a) reset is mostly useful in the development workflow b) reset shouldn’t be used instead of stop, rather you use start/stop and when stop fails you do reset once you clean stuff up However, I see how you could return a set of Vars which failed to stop on reset which might be helpful

yep, exactly

or should I say precisely.. always confuse the two