On 3 October 2017 at 19:34, Konstantinos Tsakalozos
<kos.tsakalo...@canonical.com> wrote:
> Hi,
>
> It seems the reactive framework is flushing the states at the end of hook
> execution. This may surprise charm authors. Consider the following code:
>
> @when_not("initialized")
> def init():
> must_be_called_exactly_once()
> set_state("initialized")
>
> @when("initialized")
> @when_not("ready")
> def get_ready():
> this_call_fails()
> set_state("ready")
>
> As a charm author I would expect the "initialized" state set right after the
> must_be_called_exactly_once() is called. However, the framework is not
> persisting the "initialized" state at that point, and it moves on to trigger
> the get_ready(). Since this_call_fails() happens on the get_ready() method
> I would expect the "initialized" state to be set when the failure is
> resolved.
The reason the charm state needs to be rolled back on hook failure is
that the changes made to the Juju environment get rolled back on hook
failure. If must_be_called_exactly_once() set a property on a relation
for example, then that change is rolled back by Juju when
this_call_fails() puts the unit into an error state. If init() was not
rerun, then that relation change would never happen (because the charm
thinks it has been made). This is one reason why handlers need to be
idempotent.
--
Stuart Bishop <stuart.bis...@canonical.com>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
