Comment 5 for bug 2037120

Note also that the steps outlined in the description describes (IIANM) a scenario where all the following happen inside a secret changed hook:

get the old value of the secret:
    event.secret.get_content()

get the new value of the secret:
    event.secret.peek_content()

run any activities that need the secrets (e.g. changing a password in the database)

commit back to Juju that revision N-1 is obsolete
    event.secret.get_content(refresh=True)

finish the event: doFlush will be called from the juju agent side

--

The "commit back to juju that rev N-1 is obsolete" step (get with refresh=True)...

this will currently fail with an error for the secret owner since the (current) design is that owners always read the last value written. Also note that being the owner of the secret, the full metadata and latest value is pre-cached in the hook and fetched from that context without a server side call being needed, so the --refresh is irrelevant even without the error being raised.

So some thought and work is needed if we want to have the get behaviour as provided to the secret owner be the same as that of just a "normal" (non-owner) consumer. We also have to consider cases where get is called in the same hook as that which just did any update, as opposed to doing the get in the resulting secret changed hook.
Changing behaviour will/might break existing charms that always expect to owners read the latest value. Maybe that's ok as this is still all relatively new.