[juju secrets] Secret created with existing label does not throw an error

Created 2 secrets with the same label. Ops returned ID’s for both. But juju secrets shows only one secret

Sample code:

    def _test_secrets_action(self, event: ActionEvent) -> None:
        if not self.unit.is_leader():
            event.fail("Please run action on lead unit.")
            return
        logger.warning("test-secrets action event triggered")
        secret = self.model.app.add_secret(
            {'test': 'test'},
            label="test-key",
        )
        logger.warning(f"Test Secret created: {secret.id}")

        secret1 = self.model.app.add_secret(
            {'test1': 'test1'},
            label="test-key",
        )
        logger.warning(f"Test Secret1 created: {secret1.id}")

        """
        secret_ = self.model.get_secret(id=secret.id)
        data = secret_.get_content()
        logger.warning(f"Test secret retrieved {secret_}")
        """
        data = None
        event.set_results({"secret": data})

Action result:

$ juju run keystone/0 -- test-secrets 
Running operation 7 with 1 task
  - task 8 on unit-keystone-0

Waiting for task 8...
secret: None

Logs:

unit-keystone-0: 09:08:41 WARNING unit.keystone/0.juju-log test-secrets action event triggered
unit-keystone-0: 09:08:41 WARNING unit.keystone/0.juju-log Test Secret created: secret:cdupbgfopaas7rqbqi9g
unit-keystone-0: 09:08:41 WARNING unit.keystone/0.juju-log Test Secret1 created: secret:cdupbgfopaas7rqbqia0

Juju secrets:

$ juju secrets
ID                    Owner     Rotation  Revision  Last updated
cdup3t7opaas7rqbqhr0  keystone  never            1  16 minutes ago  
cdup3tnopaas7rqbqhrg  keystone  hourly           1  16 minutes ago  
cdup4efopaas7rqbqhvg  keystone  never            1  15 minutes ago  
cdupbgfopaas7rqbqi9g  keystone  never            1  13 seconds ago

Juju secret didnt show secret:cdupbgfopaas7rqbqia0

Environment details:

juju 3.0/edge + microk8s
ops framework -  secrets branch

[wallyworld]

If the hook fails for any reason it will be re-executed.

The preliminary check will be useful because we cache on the hook context the secrets owned by the unit/app so it should be able to do the right thing. Either way, the OF needs to handle the hook failure.

[benhoyt]

Fixed in https://github.com/juju/juju/pull/14923 – thanks @wallyworld.