fix(testing): set JUJU_REMOTE_APP and allow fetching relation data in relation-broken #1130
Conversation
|
Note that the canonical/nginx-ingress-integrator-operator tests pass under this branch. |
|
The spacing changes in pebble.py and docs/conf.py are ones that Ruff wants. This seems to be a change in 0.2.2 (#9266), but I'm not sure why it didn't show up in the PR that bumped ruff to 0.2.2. I don't love the Pebble change, but I think I prefer it to a bunch of |
|
@jameinel Would be good to have your eyes on this too, seeing we've discussed this before and you commented on the issue. |
This was figured out in #1134 - the version was |
| raise KeyError( | ||
| 'Cannot index relation data with "None".' | ||
| ' Are you trying to access remote app data during a relation-broken event?' | ||
| ' This is not allowed.') | ||
| return self._data[key] |
There was a problem hiding this comment.
would we want to have a different check in case key is None? Just to avoid weird KeyError failures.
I don't know that it is necessary, but I like giving better errors when we can.
There was a problem hiding this comment.
Tony and I discussed, and we'd like our principle to be "we've invested in type annotations, let's go all in on static type checking and let that catch this." Most charming teams are using MyPy and PyRight already, and those that aren't, I think we should nudge them in that direction.
| @@ -2167,21 +2167,9 @@ def relation_remote_app_name(self, relation_id: int) -> Optional[str]: | |||
| if relation_id not in self._relation_app_and_units: | |||
| # Non-existent or dead relation | |||
| return None | |||
| if 'relation_broken' in self._hook_is_running: | |||
There was a problem hiding this comment.
is _hook_is_running used for anything else? or was this the use case and we can pull it out?
There was a problem hiding this comment.
It's used for bypassing access control on relation data as well.
|
I should do a CHANGES entry for this I think. |
|
I've run this branch against the unit tests of 132 charms (all passing with current main of ops) and they all continue to pass. |
…review suggestion.
Co-authored-by: Ben Hoyt <benhoyt@gmail.com>
benhoyt
changed the title
@tonyandrewmeyer is this a recent change? I remember encountering an occasional issue on juju 2.9 where |
The Juju team couldn't find a way to reproduce it (they tried recently). Most significantly, there was consensus that it should be always set, so having ops try to be consistent or work around a bug wasn't a good move. If you know/find a way to reproduce, please open a Juju bug (or re-open the old one) with steps and we can make sure it gets fixed there. |
sorry for the delay, didn't have a chance to try to reproduce this until now was able to reproduce, steps in Juju bug: https://bugs.launchpad.net/juju/+bug/1960934/comments/15 |
As far as the Juju team and I have been able to tell (see comments in the Juju issue)
JUJU_REMOTE_APPis always set in relation-broken events.This PR removes the
Harnessbehaviour that simulatesJUJU_REMOTE_APPnot being available (which was never consistently the case anyway) and the model code that blocks getting remote data during relation-broken (which is discouraged in the case where the entire integration is going away, but is permitted).Fixes #1128.