### Summary Emoji reactions (award emoji) cannot be read with a composite identity token issued for Duo Agent Platform custom flows (scope: `ai_workflows`). Both API surfaces fail, in different ways: - **REST** — `lib/api/award_emoji.rb` does not declare `allow_access_with_scope :ai_workflows`, so every endpoint exposed by `API::AwardEmoji` returns `403 insufficient_scope` for an `ai_workflows`-scoped token. - **GraphQL** — `Note.awardEmoji` does not declare the scope, so the connection resolves to `null` with no entry in the `errors` array. This looks like an omission rather than an intentional restriction: - Sibling REST endpoints already declare the scope — `lib/api/notes.rb:15` and `lib/api/discussions.rb:11` both allow `ai_workflows` for GET. - Sibling GraphQL fields on the same interface already declare it — `Types::Notes::BaseNoteInterface` has `author` (:12), `body` (:21) and `created_at` (:37) scoped, but not `award_emoji` (:15). - `NoteType` already declares `ai_workflows` in `authorization_scopes` (:22-24), so the note object itself is reachable, while `award_emoji` remains outside the scope allowlist. - `AwardEmojiPolicy` merely delegates to the awardable's read ability (`can?(:"read_#{awardable.to_ability_name}")`). Since the note is already readable by these tokens, the policy layer already permits this read; the scope allowlist is what blocks it. ### Steps to reproduce 1. Set up a Duo Agent Platform custom flow whose agent exposes the built-in `gitlab_api_get` and `gitlab_graphql` tools (composite identity token, scope `ai_workflows`). 2. Have a user add a reaction (for example `thumbsdown`) to a note on a merge request. 3. From the flow, read that reaction via REST: ``` GET /api/v4/projects/<project_id>/merge_requests/<mr_iid>/notes/<note_id>/award_emoji ``` 4. From the same flow, read it via GraphQL: ```graphql query { note(id: "gid://gitlab/DiffNote/<note_id>") { id awardEmoji(first: 100) { nodes { name user { username } } } } } ``` ### What is the current bug behavior? REST returns: ``` HTTP 403 insufficient_scope ``` GraphQL succeeds but the connection is null, with no error: ```json { "data": { "note": { "id": "gid://gitlab/DiffNote/<note_id>", "awardEmoji": null } } } ``` Changing the service account's role (Developer / Maintainer / Owner) has no effect. Control test — the same REST endpoint with a regular user PAT returns `200`, and the same GraphQL query in a regular session returns the `thumbsdown` node, so the endpoint, the query and the note global ID are all valid. The only difference is the authorization context. **User impact**: an authorized note with no reactions returns `nodes: []`, whereas this failure returns a bare `null` with no accompanying error. A client that treats a nullable field's `null` as missing or empty data will therefore read "reactions could not be accessed" as "there are no reactions", and automation built on custom flows can reach the wrong conclusion — for example, treating a comment that was thumbs-downed as having received no feedback. ### What is the expected correct behavior? With a token carrying the `ai_workflows` scope, and subject to the unchanged `read_emoji` / `read_note` policy checks: - The REST award emoji endpoints are readable (GET). - `Note.awardEmoji` returns a normal connection (`nodes: []` when there are no reactions). ### Root cause Composite identity tokens carry only `ai_workflows` + `mcp` + `user:<id>` (`ee/app/services/ai/duo_workflows/create_composite_oauth_access_token_service.rb:18`), and neither API surface accepts that scope here by default. GraphQL fields and object types default to `%i[api read_api]` (`app/graphql/types/base_field.rb:27`, `app/graphql/types/base_object.rb:33`). REST registers `api` and read-only `read_api` globally in `lib/api/api.rb:68-69`; `API::AwardEmoji` neither includes `APIGuard` nor adds `ai_workflows` to the scopes accepted by its endpoints. For GraphQL, the scope check is evaluated before the policy/ability check (`Gitlab::Graphql::Authorize::ObjectAuthorization#ok?` evaluates `scopes_ok?` first), so changing the member role cannot affect the observed failure. When field authorization rejects the request, `GitlabSchema.unauthorized_field` (`app/graphql/gitlab_schema.rb:173`) falls back to GraphQL-Ruby's default behavior, returning `null` without adding a top-level error. Making this work spans three source files and several authorization layers. **REST** — `lib/api/award_emoji.rb` neither includes `APIGuard` nor declares any allowed scope. Compare `lib/api/notes.rb:5-17`, which does both: ```ruby class Notes < ::API::Base include PaginationParams include APIGuard ... allow_access_with_scope :ai_workflows, if: ->(request) do request.get? || request.head? || request.post? end ``` **GraphQL, field layer** — `app/graphql/types/notes/base_note_interface.rb:15`. This is the layer responsible for the `null` observed today; execution stops here and never reaches the award emoji type: ```ruby field :award_emoji, Types::AwardEmojis::AwardEmojiType.connection_type, null: true, description: 'List of emoji reactions associated with the note.' # no scopes: -> [:api, :read_api] ``` **GraphQL, type and field layers below it** — these do not contribute to the current `null`, but each becomes the next blocker once the field above is fixed: - `app/graphql/types/award_emojis/award_emoji_type.rb` does not override `authorization_scopes`, so the type-level check would reject the token before any of its fields resolve. Compare `NoteType:22-24`: ```ruby def self.authorization_scopes super + [:ai_workflows] end ``` - None of `AwardEmojiType`'s own fields (`name`, `description`, `unicode`, `emoji`, `unicode_version`, `user`) declare the scope either. ### Possible fixes 1. `lib/api/award_emoji.rb` — add `include APIGuard` alongside the existing `include PaginationParams`, then declare the scope. A single class-level declaration covers all generated endpoints (issues, merge requests, snippets — both the awardable and the `notes/:note_id` variants): ```ruby include APIGuard allow_access_with_scope :ai_workflows, if: ->(request) do request.get? || request.head? end ``` 2. `app/graphql/types/notes/base_note_interface.rb:15` — add `scopes: [:api, :read_api, :ai_workflows]` to `award_emoji`. 3. `app/graphql/types/award_emojis/award_emoji_type.rb` — add `def self.authorization_scopes; super + [:ai_workflows]; end`, plus `scopes: [:api, :read_api, :ai_workflows]` on at least `name` and `user`. ### Authorization boundary This intentionally allows `ai_workflows`-scoped tokens to read award emoji data, which they cannot read today. Existing `read_emoji` and `read_note` policy checks remain unchanged and continue to gate access to the underlying resources, so the change grants this scope no visibility beyond what the token's identity is already permitted to see on the parent awardable or note. ### Related - gitlab-org/gitlab#606488 — the same class of gap on `Query.group` / `Query.groups`, being addressed by the open MR gitlab-org/gitlab!246187.