fix: remove private-address from relation databags for Juju 4.0+

[Copilot]

Juju 4.0 no longer includes private-address in the default relation databags. The Scenario testing framework was incorrectly including it for all Juju versions.

Changes

• Runtime processing: Modified Runtime.exec() to remove private-address from all relation databags when simulating Juju 4.0+, applied after state deep-copy where both state and Juju version are available
• Relation type coverage: Handles Relation, SubordinateRelation, and PeerRelation databags (local unit, remote units, and peers)
• Tests: Added parameterized tests verifying presence in Juju 3.x and absence in Juju 4.0+

Example

from scenario import Context, State
from scenario.state import Relation

# Juju 3.6: private-address is present
ctx = Context(MyCharm, juju_version='3.6.4')
rel = Relation(endpoint='foo', interface='foo')
ctx.run(ctx.on.relation_changed(rel), State(relations={rel}))
# relation.data[unit] contains: egress-subnets, ingress-address, private-address

# Juju 4.0: private-address is absent
ctx = Context(MyCharm, juju_version='4.0.0')
rel = Relation(endpoint='foo', interface='foo')
ctx.run(ctx.on.relation_changed(rel), State(relations={rel}))
# relation.data[unit] contains: egress-subnets, ingress-address

The solution avoids modifying Relation constructors (where Juju version is unavailable) by processing databags post-deepcopy in the runtime where both state and version are accessible.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Don't include private-address in the default Scenario database when mocking Juju 4</issue_title>
<issue_description>The private-address key is not included in the default relation settings (databag) as of Juju 4.0, so we should not include it in the mock one either, if the mock Juju version is 4.0+.

The default contents are currently set when a Relation (etc) object is created. We don't have access to the relevant Context object at that time (which is where the Juju version is), so we'll have to figure out what the best way of handling this is.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Don't include private-address in the default Scenario database when mocking Juju 4 #2185

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dimaqq]

@tonyandrewmeyer wdyt about this approach?

[tonyandrewmeyer]

@tonyandrewmeyer wdyt about this approach?

Yeah, this is tricky because the user/test may be doing something with the database contents before the run, so it'll be wrong for Juju 4 in that situation. In general I think it'd be nicer to have the modern version as the default (so add private-address in 3 rather than remove in 4) but this is the more backwards compatible way to do it, so probably what we have to do.

I can only think of three approaches here:

• What you're doing here, which is correct at the time the charm code executes but incorrect/confusing before that.
• Make it easier to use an explicit argument with RelationBase - _JUJU_DEFAULT_DATABAG but public and with 3 and 4 versions and probably a shorter name? - and for backwards compatibility it probably has to stay using 3 as the default. Most explicit and most correct but relies on users knowing they need to do this and probably paramterising their tests.
• Close/reject the ticket and leave this as-is (or perhaps just change the documentation), forcing users to deal with it.

I don't mind some magic in Scenario, so if we could do the first one and have it right throughout the test, I'd pick that. I think mostly these values are ignored (e.g. tests don't take care to retain the values when they populate the databags) so it probably doesn't matter that much. But I don't love the behaviour of "this field is there but will be deleted at runtime", when that isn't what Juju does. I guess I lean more towards option 2 above.

What's your thinking? Did you push copilot towards this solution, or like the one it chose? Or it's just the one copilot came up with?

[dimaqq]

My take:

1. reasonable
2. somehow I'm not feeling it
3. reasonable

Let's discuss at a stand-up when we have quorum.