relation-set --app peer causes the leader to wake up again

[John A Meinel]

It seems that if a leader decides to set application data of a peer relation, it then gets a relation-changed event for the peer relation to let it know that there is new app data.

This has been determined to only happen if you set genuinely new data (eg, relation-set --app foo=bar, relation-set --app foo=bar will only trigger 1 relation-changed event.)

It still feels suboptimal and charms shouldn't plan on abusing this feature.

[John A Meinel (jameinel)]

https://pastebin.canonical.com/p/jyvCYnwJvb/

Would hint that this is actually just that if there is any application data in a peer relation, we never stop firing relation-changed. AFAICT that hook is not actually setting new data in the event.

[John A Meinel (jameinel)]

https://pastebin.canonical.com/p/khMPWtx5pw/

seems to indicate that the charm is calling relation-set but according to discussion it is setting the content to the same value as it currently has (eg, no actual change).
Do we always trigger hooks in response to relation-set, even if the data doesn't change?

[John A Meinel (jameinel)]

I can confirm that the app wakes up, but not that the app fires a second time without K8s:

If I have a charm doing this:
+ def _on_relation_created(self, event):
+ logging.info(f'relation-created for {self.unit.name}'
+ f' unit {event.unit} app {event.app} data {event.relation.data[event.app]}'
+ f'\nsetting app data foo=created')
+ event.relation.data[self.app]['foo'] = 'created'
+
+ def _on_relation_joined(self, event):
+ logging.info(f'relation-joined for {self.unit.name}'
+ f' unit {event.unit} app {event.app} data {event.relation.data[event.app]}'
+ f'\nsetting app data foo=joined')
+ event.relation.data[self.app]['foo'] = 'joined'
+
+ def _on_relation_changed(self, event):
+ logging.info(f'relation-changed for {self.unit.name}'
+ f' unit {event.unit} app {event.app} data {event.relation.data[event.app]}'
+ f'\nsetting app data foo=changed')
+ event.relation.data[self.app]['foo'] = 'changed'
+

Then in the logs I see:

unit-uo-0: 16:59:39 INFO unit.uo/0.juju-log peer:0: relation-created for uo/0 unit None app <ops.model.Application uo> data {}
setting app data foo=created
unit-uo-0: 16:59:42 INFO unit.uo/0.juju-log peer:0: relation-changed for uo/0 unit None app <ops.model.Application uo> data {'foo': 'created'}
setting app data foo=changed
unit-uo-0: 16:59:43 INFO unit.uo/0.juju-log peer:0: relation-changed for uo/0 unit None app <ops.model.Application uo> data {'foo': 'changed'}
setting app data foo=changed

So it sees relation-created, and because it sets a value, it then gets relation-changed, but when it sets the value a second time, it doesn't trigger *another* relation-changed.

[John A Meinel (jameinel)]

Note that if I then do:
juju run --unit uo/0 "relation-set --app -r 0 foo=changed"

There is no change in debug-log (which means we treat the no-op change as do-nothing), but if I do:

juju run --unit uo/0 "relation-set --app -r 0 foo=bar"

then I see:
unit-uo-0: 17:02:46 INFO unit.uo/0.juju-log peer:0: relation-changed for uo/0 unit None app <ops.model.Application uo> data {'foo': 'bar'}
setting app data foo=changed
unit-uo-0: 17:02:46 INFO unit.uo/0.juju-log peer:0: relation-changed for uo/0 unit None app <ops.model.Application uo> data {'foo': 'changed'}
setting app data foo=changed

Which indicates it sees that foo was set to bar, and changes it back to 'changed' which triggers it to again see that app data has changed and set it (again) to 'changed', but does not wake it up again.

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.