MGS1103: this provider did not say who opened the review

magus asked the review provider who opened this review and who the credential belongs to, and did not get both. So it cannot tell whether approving would be approving your own change, and the verdict is limited to remarks.

[MGS1103] magus could not tell who opened this review, so it will not approve on
your behalf

Your remarks still publish. Only the verdict is narrowed.

Why

A review may approve a colleague's change and must never approve one its own credential opened. The provider API is perfectly happy to let a change approve itself, which is why the rule lives in magus rather than in a spell you could edit around.

Deciding it needs two names: the review's author, and the viewer the token belongs to. A provider that answers neither leaves the question open, and an open question has three states rather than two:

The third row is this code. Collapsing it into the first would be convenient and wrong: they are different facts, and only one of them is a gap you could close. Resolving it toward the second would be worse - not knowing is not permission.

Fix

• Answer both fields from find_review. A provider returns author (who opened the review) and viewer (who the credential belongs to). The GitHub spell reads the second from GET /user, and only when magus asks for it - a lookup nobody needs is a request nobody should pay for.
• Check the token has the scope to identify itself. A credential that can read a pull request but not its own user is the commonest cause.
• Approve in the forge, if the provider cannot be extended. magus narrows its own surface rather than guessing; it does not stop you.

See also

• MGS1102 - a provider that does not implement an op at all.
• Review - what a published review says, and who may say it.