-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(testing): set JUJU_REMOTE_APP and allow fetching relation data in relation-broken #1130
Changes from all commits
a832115
6a82b7f
c5e3778
99cdecd
a527498
aa7ab0c
63597e1
ce1cdba
03e22b6
20ffba3
bb5ee72
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's used for bypassing access control on relation data as well. |
||
# TODO: if juju ever starts setting JUJU_REMOTE_APP in relation-broken hooks runs, | ||
# then we should kill this if clause. | ||
# See https://bugs.launchpad.net/juju/+bug/1960934 | ||
return None | ||
return self._relation_app_and_units[relation_id]['app'] | ||
|
||
def relation_get(self, relation_id: int, member_name: str, is_app: bool): | ||
if 'relation_broken' in self._hook_is_running and not self.relation_remote_app_name( | ||
relation_id) and member_name != self.app_name and member_name != self.unit_name: | ||
# TODO: if juju gets fixed to set JUJU_REMOTE_APP for this case, then we may opt to | ||
# allow charms to read/get that (stale) relation data. | ||
# See https://bugs.launchpad.net/juju/+bug/1960934 | ||
raise RuntimeError( | ||
'remote-side relation data cannot be accessed during a relation-broken event') | ||
if is_app and '/' in member_name: | ||
member_name = member_name.split('/')[0] | ||
if relation_id not in self._relation_data_raw: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.