Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 14, 2025

The error message when attempting to manage a secret with owner=None was contradictory. The documentation states that owner=None means the secret has been granted for read access, but the error claimed the secret was "not owned by this unit/app or granted to it".

Changes:

  • Updated error message in _check_can_manage_secret: Changed from "not owned by this unit/app or granted to it. Did you forget passing it to State.secrets?" to "not owned by this unit/app. Did you forget passing it to State.secrets?" to align with the documented behavior that owner=None indicates a granted (read-only) secret.

The error now correctly conveys that secrets need to be owned (owner='unit' or owner='app') for management operations, not merely granted, while keeping the original hint about passing the secret to State.secrets.

<issue_title>Fix docs/impl inconsistency in Secret ownership in ops[testing]</issue_title>
><issue_description>Code:
>
> py &gt; def _check_can_manage_secret( &gt; self, &gt; secret: Secret, &gt; ): &gt; if secret.owner is None: &gt; raise SecretNotFoundError( &gt; 'this secret is not owned by this unit/app or granted to it. ' &gt; 'Did you forget passing it to State.secrets?', &gt; ) &gt; ... &gt;
>
> Docs:
>
> > owner: Literal['unit', 'app', None] = None
> > Indicates if the secret is owned by this unit, this application, or another application/unit.
> >
> > If None, the implication is that read access to the secret has been granted to this unit.</issue_description>
>
><agent_instructions>Make a PR with a minimal change to fix this.</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
>
><comment_new>@dimaqq
> cc @tonyandrewmeyer </comment_new>
><comment_new>@dimaqq
> In term of logic the above is actually correct (this unit can't manage granted secrets).
>
> In term of the error message though, this is confusing, if None really means granted.</comment_new>
><comment_new>@dimaqq
> quick fix: dimaqq#72
>
> I want to think a bit more about a more comprehensive fix... maybe.</comment_new>
><comment_new>@tonyandrewmeyer
> I don't think the code or doc is wrong. None means that it's a secret that the unit only has view access to, so the unit can't do management of the secret, but can view it.
>
> I suspect maybe that error text was wrongly copied from somewhere else. It should instead say that the secret is not owned by the unit/app, did you forget to set the owner.</comment_new>
>
>

Original prompt

This section details on the original issue you should resolve

<issue_title>Fix docs/impl inconsistency in Secret ownership in ops[testing]</issue_title>
<issue_description>Code:

      def _check_can_manage_secret(
          self,
          secret: Secret,
      ):
          if secret.owner is None:
              raise SecretNotFoundError(
                  'this secret is not owned by this unit/app or granted to it. '
                  'Did you forget passing it to State.secrets?',
              )
          ...

Docs:

owner: Literal['unit', 'app', None] = None
Indicates if the secret is owned by this unit, this application, or another application/unit.

If None, the implication is that read access to the secret has been granted to this unit.</issue_description>

<agent_instructions>Make a PR with a minimal change to fix this.</agent_instructions>

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

@dimaqq cc @tonyandrewmeyer @dimaqq In term of logic the above is actually correct (this unit **can't manage** granted secrets).

In term of the error message though, this is confusing, if None really means granted.</comment_new>
<comment_new>@dimaqq
quick fix: dimaqq#72

I want to think a bit more about a more comprehensive fix... maybe.</comment_new>
<comment_new>@tonyandrewmeyer
I don't think the code or doc is wrong. None means that it's a secret that the unit only has view access to, so the unit can't do management of the secret, but can view it.

I suspect maybe that error text was wrongly copied from somewhere else. It should instead say that the secret is not owned by the unit/app, did you forget to set the owner.</comment_new>


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI and others added 2 commits November 14, 2025 12:30
Co-authored-by: dimaqq <662249+dimaqq@users.noreply.github.com>
Co-authored-by: dimaqq <662249+dimaqq@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix inconsistency in Secret ownership documentation Fix confusing error message for non-owned secrets in ops.testing Nov 14, 2025
Copilot AI requested a review from dimaqq November 14, 2025 12:36
@dimaqq
Copy link
Contributor

dimaqq commented Nov 15, 2025

@copilot there's no need for the new test; existing tests already cover this.
the exception text should be this secret is not owned by this unit/app. Did you forget passing it to State.secrets?

Co-authored-by: dimaqq <662249+dimaqq@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Nov 15, 2025

@copilot there's no need for the new test; existing tests already cover this.
the exception text should be this secret is not owned by this unit/app. Did you forget passing it to State.secrets?

Done. Removed the new test and updated the error message to keep the original State.secrets hint. The error message now reads: 'this secret is not owned by this unit/app. Did you forget passing it to State.secrets?'

Changes in commit ab4e79e.

@dimaqq dimaqq closed this Nov 16, 2025
@dimaqq dimaqq reopened this Nov 16, 2025
@dimaqq dimaqq marked this pull request as ready for review November 16, 2025 23:28
@dimaqq dimaqq changed the title Fix confusing error message for non-owned secrets in ops.testing chore: fix error message for non-owned secrets in ops.testing Nov 16, 2025
Copy link
Collaborator

@tonyandrewmeyer tonyandrewmeyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropping "or granted to it" is a good improvement, but we should also fix the recommendation as well, since it's also wrong.

Also: the PR description is quite messy with all the Copilot stuff. Let's make sure to either clear that out now or remove it when doing the merge.

raise SecretNotFoundError(
'this secret is not owned by this unit/app or granted to it. '
'this secret is not owned by this unit/app. '
'Did you forget passing it to State.secrets?',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggestion is not correct - any time we get into _check_can_manage_secret we have retrieved the secret from the state, so we know that it's there.

What we should suggest is that they forgot to set the owner attribute on the testing.Secret.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered that based on your comment on the issue. Sadly it looks like my comment along those lines got eaten (I probably left it in 'preview' mode before I submitted my review). Thanks for catching this.

@james-garner-canonical james-garner-canonical dismissed their stale review November 16, 2025 23:46

Error message suggested fix isn't correct per @tonyandrewmyer's comment.

@dimaqq dimaqq marked this pull request as draft November 17, 2025 06:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix docs/impl inconsistency in Secret ownership in ops[testing]

4 participants