Skip to content

fix: should not error if can access to api keys, close #1674#1697

Merged
looplj merged 1 commit into
unstablefrom
dev-tmp
May 22, 2026
Merged

fix: should not error if can access to api keys, close #1674#1697
looplj merged 1 commit into
unstablefrom
dev-tmp

Conversation

@looplj

@looplj looplj commented May 22, 2026

Copy link
Copy Markdown
Owner

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

Open in Devin Review

@greptile-apps

greptile-apps Bot commented May 22, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR fixes a bug where API key requests would surface a permission denied GraphQL error when resolving associated channel or user fields that the key's scope doesn't permit access to. The fix treats privacy.Deny the same as "not found" in the two nilable-entity helpers.

  • getNilableChannel and getNilableUser now return (nil, nil) when ent's privacy layer emits a privacy.Deny error, so callers receive a null field rather than a resolver error, which is consistent with the existing IsNotFound handling and the functions' stated nilable contract.

Confidence Score: 5/5

Safe to merge — the change is a small, well-scoped addition that makes nilable-entity resolvers return null instead of a resolver error when the privacy layer denies access.

Both helpers already treat not-found as (nil, nil); extending that same treatment to privacy.Deny is the natural and correct completion of that contract. The existing GraphQL error presenter already handles privacy.Deny at the boundary for non-nilable paths, so this change doesn't remove any error visibility for callers that need it.

No files require special attention.

Important Files Changed

Filename Overview
internal/server/gql/graphql.go Adds privacy.Deny early-exit (return nil, nil) to getNilableChannel and getNilableUser, matching the existing IsNotFound pattern. Minimal, targeted, and consistent with the error presenter that already handles privacy.Deny at the GraphQL boundary.

Sequence Diagram

sequenceDiagram
    participant Resolver as GQL Resolver
    participant Helper as getNilableChannel / getNilableUser
    participant Ent as ent.Client (Query)
    participant Privacy as Privacy Layer

    Resolver->>Helper: getNilableChannel(ctx, client, id)
    Helper->>Ent: .Query().Where(id).First(ctx)
    Ent->>Privacy: evaluate access rules
    alt Access allowed
        Privacy-->>Ent: Allow
        Ent-->>Helper: entity
        Helper-->>Resolver: (entity, nil)
    else Not found
        Privacy-->>Ent: (pass-through)
        Ent-->>Helper: IsNotFound error
        Helper-->>Resolver: (nil, nil)
    else Privacy denied (NEW)
        Privacy-->>Ent: privacy.Deny
        Ent-->>Helper: privacy.Deny error
        Helper-->>Resolver: (nil, nil)
    else Other error
        Ent-->>Helper: other error
        Helper-->>Resolver: (nil, wrapped error)
    end
Loading

Reviews (1): Last reviewed commit: "fix: should not error if can access to a..." | Re-trigger Greptile

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request updates the getNilableChannel and getNilableUser functions in internal/server/gql/graphql.go to handle privacy.Deny errors. When a privacy denial occurs, the functions now return nil instead of an error, effectively treating restricted entities as non-existent. I have no feedback to provide as no review comments were submitted.

@looplj looplj merged commit 9226ee3 into unstable May 22, 2026
5 checks passed
yoke233 pushed a commit to yoke233/axonhub that referenced this pull request May 26, 2026
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.

1 participant