Testing harness does not re-emit deferred event

I have an event handler that should be deferring the event under certain conditions [1]. In a test case [2], I reproduced the conditions for event.defer() to be triggered but the test harness does not re-emit the deferred event.

My workaround is to manually emit the event in the testing harness with this line: [3]

[1] https://github.com/justinmclark/grafana-charm-base/blob/5d7f2a5210c27b5da6122704efaeb8e8ff6cec1e/src/charm.py#L127 [2] https://github.com/justinmclark/grafana-charm-base/blob/5d7f2a5210c27b5da6122704efaeb8e8ff6cec1e/test/unit/test_charm.py#L60 [3] https://github.com/justinmclark/grafana-charm-base/blob/5d7f2a5210c27b5da6122704efaeb8e8ff6cec1e/test/unit/test_charm.py#L84

[jameinel]

For the original statement about Harness not triggering deferred events, that is true. Doing something like “Harness.add_relation()” which ends up deferred and then “Harness.update_config” won’t currently fire the deferred event before processing the config-changed event. We could certainly do so, and it is more how actual charm events would be triggered, it is more a case of refactoring how the Harness is emitting events so that we don’t miss a case (eg, config-changed would fire deferred, but relation-changed wouldn’t).

As for the other concern, it is still true that deferred events fire before the next event. so the order would be:

peer-relation-joined (deferred) deferred-peer-relation-joined (deferred again) db-relation-joined deferred-peer-relation-joined config-changed etc.

Note that Juju does not make any guarantee about relation-joined ordering. It is as likely that peer-relation-joined will fire before or after db-relation-joined (I might be wrong about peer relations, but IIRC Juju is just iterating a map, which means they are not deterministic.)

Note also that “relation-joined” events often happen before a unit has been able to set any actual relation content. (Both sides join the relation, and get the opportunity to start telling the other side information.) So the real event that you probably want to deal with is “relation-changed”.

To clarify, it is a matter of ordering. Once unit prometheus/0 has finished the ‘start’ hook, and postgresql/0 has finished the start hook, they join their respective relations. However, there is no guarantee whether postgresql/0 will see ‘pgsql-relation-joined’ before or after prometheus/0 sees ‘db-relation-joined’. As that depends on lots of factors like what machine starts first, which one is more heavily loaded, how many other things are related, etc. So while it is perfectly acceptable to check if the data you need (like the database URL) is available during relation-joined, if it isn’t present, then the recommendation is not to defer db-relation-joined, but instead to wait for db-relation-changed.

If you defer db-relation-joined, it will fire before every other hook (config-changed, peer-relation-joined, other-app-relation-changed, etc), with no expectation that the data on the relation has actually changed.

In your particular case about HA prometheus needing a database, I probably would set a BlockedStatus, but I probably would not defer peer-relation-joined. What you are really waiting on is an event that isn’t peer-relation-joined, so it doesn’t really make sense that you would want to be told about it yet-another-time before any other operation.

Does that make sense?

[stub42]

An explicit call to self.harness.framework.reemit() will reemit deferred events, which I’m using to confirm that non-peers are correctly deferring an event until the leader has published required data. https://github.com/canonical/ops-lib-pgsql/blob/f16114b3c8d7411c1bb15e86867f20282be34a36/tests/test_client.py#L893