feat(policy): Add sort support to ListNamespaces API

[dsm20]

Summary

Adds strongly-typed single-field sort capability to the ListNamespaces RPC. Defines a
SortNamespacesType enum and NamespacesSort message per the strongly-typed approach
agreed on in DSPX-2680, then wires it through to CASE WHEN SQL ordering via sqlc.

Resolves DSPX-2681
Depends on DSPX-2680 (shared SortDirection enum in selectors.proto)

Changes

Proto — service/policy/namespaces/namespaces.proto

• Added SortNamespacesType enum (NAME, FQN, CREATED_AT, UPDATED_AT)
• Added NamespacesSort message (embeds enum + SortDirection)
• Added repeated NamespacesSort sort to ListNamespacesRequest with max 1 protovalidate
  constraint
• Regenerated protos and docs

SQL — service/policy/db/queries/namespaces.sql

• CASE WHEN ORDER BY blocks for 4 fields x 2 directions + created_at DESC fallback

Go — service/policy/db/utils.go + service/policy/db/namespaces.go

• GetNamespacesSortParams: maps enum → SQL-compatible field/direction strings
• ListNamespaces handler calls it via r.GetSort()

Tests

• 9 unit tests for the enum mapper (nil, empty, unspecified, each field + direction)
• 6 integration tests (sort by name ASC/DESC, created_at ASC, fqn ASC, updated_at DESC,
  unspecified fallback)

Deferred

• otdfctl --sort flag for policy namespaces list — will hit all CLI changes after finishing changes to API.

Design Decisions

1. Strongly-typed sort enums — Per team discussion on DSPX-2680, each entity defines
   its own sort enum rather than using a generic string field. Valid sort fields are
   discoverable via IDE autocomplete and enforced at compile time.

2. CASE WHEN ORDER BY in sqlc — Each sortable field gets two CASE blocks (ASC + DESC),
   grouped by column type. The enum mapper in Go converts the proto enum to strings that
   match the SQL CASE conditions.

3. Silent fall-through for UNSPECIFIED — SORT_NAMESPACES_TYPE_UNSPECIFIED returns
   empty strings, causing all CASE branches to evaluate to NULL. The created_at DESC
   tiebreaker takes over.

4. Integration tests over unit tests — Ticket AC says "unit tests" but sort behavior
   requires a real DB. Written as integration tests following existing codebase precedent.
   Unit tests cover the enum mapper separately.

Test Plan

• golangci-lint passes (0 issues)
• Unit tests pass (go test ./service/policy/db/...)
• Integration tests compile (go build ./service/integration/...)
• Integration tests pass in CI

Checklist

• I have added or updated unit tests
• I have added or updated integration tests (if appropriate)
• I have added or updated documentation

Testing Instructions

Summary by CodeRabbit

• New Features

  • Namespace listings now support client-requested sorting by name, FQN, creation time, or last-updated time, in ascending or descending order. List requests accept an optional sort specification (one item).

• Documentation

  • Added docs describing available sort fields and directions and how to include a sort in list requests.

• Tests

  • Added integration and unit tests covering sorting behavior, defaulting when unspecified, and parameter handling.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the ListNamespaces RPC by introducing robust single-field sorting capabilities. It modifies the database query to dynamically order results based on specified fields and directions, leveraging CASE WHEN clauses for flexible SQL generation. The changes include updates to the API's PageRequest to accept sort parameters, a new utility function to process these parameters, and extensive integration tests to ensure the feature's reliability and correctness. This lays the groundwork for future sort-enabled list RPCs across the platform.

Highlights

• Single-Field Sorting for ListNamespaces RPC: Implemented single-field sorting for the ListNamespaces RPC, allowing dynamic ordering of results based on specified criteria.
• Dynamic SQL Ordering with CASE WHEN: Updated the underlying SQL query to use CASE WHEN expressions for flexible sorting by name, fqn, created_at, and updated_at in both ascending and descending orders.
• Sort Parameter Extraction and Integration: Introduced a new GetSortParams utility function to parse sort requests from PageRequest and integrated it into the ListNamespaces database layer.
• API Contract Extension for Sorting: Expanded the policy/selectors.proto definition to include SortDirection enum and SortField message, enabling sort parameter specification in API requests.
• Comprehensive Integration Tests: Added extensive integration tests to verify correct sorting behavior for various fields and directions, including a fallback to default ordering for unspecified or invalid sort fields.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Ignored Files

• Ignored by pattern: protocol/**/* (1)
  • protocol/go/policy/selectors.pb.go

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

---

Data flows, a stream, Sort it, ASC or DESC, Order brings new gleam.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds request-level sorting for ListNamespaces: new proto enums/messages (SortDirection, SortNamespacesType, NamespacesSort), ListNamespacesRequest gains an optional repeated sort, helper maps proto sort to SQL, listNamespaces SQL ORDER BY made dynamic, and unit + integration tests added.

Changes

Cohort / File(s)	Summary
Protocol Definitions service/policy/selectors.proto, service/policy/namespaces/namespaces.proto	Added SortDirection enum; added SortNamespacesType enum and NamespacesSort message; added repeated NamespacesSort sort to ListNamespacesRequest (max_items = 1).
API Documentation / OpenAPI docs/grpc/index.html, docs/openapi/policy/selectors.openapi.yaml, docs/openapi/policy/namespaces/namespaces.openapi.yaml	Added documentation/OpenAPI schemas for policy.SortDirection, policy.namespaces.SortNamespacesType, and policy.namespaces.NamespacesSort; updated ListNamespacesRequest schema to include optional sort array.
Database Query SQL service/policy/db/queries/namespaces.sql	Replaced fixed ORDER BY ns.created_at DESC with parameter-driven CASE-based ORDER BY supporting name, fqn, created_at, updated_at and ASC/DESC; preserved ns.created_at DESC as final tie-breaker; pagination unchanged.
DB Go Layer service/policy/db/namespaces.sql.go, service/policy/db/namespaces.go	Added SortField/SortDirection to listNamespacesParams, adjusted parameter ordering and query invocation; PolicyDBClient.ListNamespaces derives sort params and forwards them to the query.
Utilities & Tests service/policy/db/utils.go, service/policy/db/utils_test.go	Added exported GetNamespacesSortParams(sort []*namespaces.NamespacesSort) (string, string) mapping proto enums to SQL column and direction; added unit tests covering mapping, edge cases, and defaults.
Integration Tests service/integration/namespaces_test.go	Added integration tests for ListNamespaces sorting: name ASC/DESC, FQN ASC, created_at ASC (with delays), updated_at DESC (after update), and fallback behavior when sort unspecified.
Docs HTML docs/grpc/index.html	Inserted new enum/message entries into the Table of Contents and documentation for the new sorting enums/messages.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Service
    participant DB
    Client->>Service: ListNamespacesRequest (optional sort)
    Service->>Service: GetNamespacesSortParams(sort)
    Service->>Service: Build listNamespaces params (active, offset, limit, sortField, sortDirection)
    Service->>DB: listNamespaces(params)
    DB->>DB: Apply ORDER BY CASE using sortField & sortDirection
    DB-->>Service: Sorted namespace rows
    Service-->>Client: ListNamespacesResponse

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I hop through enums, nibble a sort,
Fields align tidy in every report,
Name, FQN, dates — ASC or DESC,
I twirl them in order, neat as a nest,
Hooray — namespaces spring into best!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding sort support to the ListNamespaces API. It directly correlates with the primary objective of the PR.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/DSPX-2681-add-sort-support-list-namespaces

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request effectively introduces sorting capabilities to the ListNamespaces RPC. The implementation using CASE statements in the SQL query is a practical solution for dynamic sorting with sqlc, and the addition of comprehensive integration tests is a great step towards ensuring correctness. I have identified a critical issue that could lead to a panic, along with some opportunities to improve test correctness and reliability.

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	159.242552ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	77.489653ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	393.03501ms
Throughput	254.43 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	39.518745974s
Average Latency	393.056393ms
Throughput	126.52 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ go-v0.9.0
✅ java-pull-3192
✅ java-v0.9.0
✅ js-pull-3192
✅ js-v0.9.0
test-cases-mapping-report
bats-test-results
cukes-report
opentdfplatformE40IKX.dockerbuild

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	150.248845ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	72.814686ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	404.423708ms
Throughput	247.27 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	37.662611921s
Average Latency	375.081077ms
Throughput	132.76 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ go-v0.9.0
✅ java-v0.9.0
✅ java-pull-3192
✅ js-v0.9.0
✅ js-pull-3192
test-cases-mapping-report
bats-test-results
cukes-report
opentdfplatformY5SC22.dockerbuild

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	182.559991ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	97.951064ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	396.068463ms
Throughput	252.48 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	41.608087645s
Average Latency	414.95314ms
Throughput	120.17 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ go-v0.9.0
✅ java-pull-3192
✅ js-pull-3192
✅ java-v0.9.0
✅ js-v0.9.0
cukes-report
test-cases-mapping-report
bats-test-results
opentdfplatformS79KGR.dockerbuild

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	207.484894ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	97.03041ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	397.864951ms
Throughput	251.34 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	42.337539156s
Average Latency	420.417175ms
Throughput	118.10 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ go-v0.9.0
✅ java-pull-3192
✅ java-v0.9.0
✅ js-pull-3192
✅ js-v0.9.0
cukes-report
test-cases-mapping-report
bats-test-results
opentdfplatformZC6C8Z.dockerbuild

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	163.88479ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	82.117175ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	396.722474ms
Throughput	252.07 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	41.021207145s
Average Latency	407.766898ms
Throughput	121.89 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ java-pull-3192
✅ go-v0.9.0
✅ java-v0.9.0
✅ js-pull-3192
✅ js-v0.9.0
test-cases-mapping-report
bats-test-results
cukes-report
opentdfplatformJ1JAM0.dockerbuild

[coderabbitai]

Actionable comments posted: 7

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

docs/grpc/index.html (2)

12352-12484: ⚠️ Potential issue | 🟡 Minor

Document the actual ListNamespacesRequest.sort contract.

Because this field is repeated, the current Optional description makes multi-key sorting look valid, and NamespacesSort itself does not explain the single-field/default behavior. Add those semantics in the source comments before regenerating the page.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/grpc/index.html` around lines 12352 - 12484, Update the source protobuf
comments to clearly document the ListNamespacesRequest.sort contract: in the
comment for the ListNamespacesRequest.sort field and on the NamespacesSort
message, state that although the field is declared repeated it is optional and
only the first element is applied (i.e., single-field sorting / default
behavior), or define the explicit multi-key merge semantics if multi-key sorting
is supported; mention the default sort if none provided and reference
SortNamespacesType and SortDirection. After changing the comments on
ListNamespacesRequest.sort and NamespacesSort, regenerate the HTML docs so the
updated contract appears in the generated page.

---

7401-7482: ⚠️ Potential issue | 🔴 Critical

The HTML documentation at lines 7401-7482 incorrectly documents non-existent PageRequest.sort and SortField types.

The proto sources show PageRequest (selectors.proto) contains only limit and offset fields. There is no SortField message, and sorting is not a shared PageRequest feature. ListNamespacesRequest defines its own repeated NamespacesSort sort field, which uses the shared SortDirection enum but is request-specific, not a PageRequest capability.

Remove the incorrect PageRequest.sort, SortField documentation, and namespace-scoped references to them. The duplicated SortDirection documentation and TOC entries should also be deduplicated.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/grpc/index.html` around lines 7401 - 7482, The generated HTML
incorrectly documents a non-existent PageRequest.sort and a global SortField
message; remove the PageRequest.sort entry and the SortField section/toc
entries, and instead ensure any sorting docs reference the request-scoped sort
types (e.g., ListNamespacesRequest -> NamespacesSort) and the shared enum
SortDirection only where actually used; update/remove duplicated SortDirection
TOC/section so SortDirection appears once and is linked from request-specific
sort fields rather than from PageRequest or a global SortField.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/grpc/index.html`:
- Around line 7518-7545: The docs contain a duplicated enum section for
SortDirection (h3 id="policy.SortDirection") causing a repeated TOC entry;
locate the generator/template or source that emits the policy.SortDirection enum
(search for "SortDirection" or the template that renders enums) and remove the
duplicate emission (remove the redundant template block or stop processing the
same proto/enum twice), then regenerate the docs so the SortDirection enum
appears only once.

In `@docs/openapi/policy/attributes/attributes.openapi.yaml`:
- Around line 1299-1307: The OpenAPI spec incorrectly exposes a generic
policy.PageRequest.sort and policy.SortField (used by ListAttributes clients)
but the shipped proto only defines limit/offset and sorting is
namespace-specific via NamespacesSort; remove the generic sort and SortField
entries from the non-namespace OpenAPI artifacts and regenerate the namespace
OpenAPI from the final proto so only ListNamespaces (and
namespaces.ListNamespacesRequest.Sort / NamespacesSort) exposes sorting; verify
and remove the same stale shared-schema expansion wherever policy.PageRequest or
policy.SortField were added (see service/policy/db/namespaces.go usage and
ListAttributes references) and re-run spec generation from the final proto
contract.

In `@docs/openapi/policy/kasregistry/key_access_server_registry.openapi.yaml`:
- Around line 972-980: The shared schema documents a hardcoded fallback "Falls
back to created_at DESC" for the `sort` property which is too specific; remove
that resource-specific default from the common `sort` field (the
`policy.SortField`/`sort` schema) and instead document any concrete fallback
per-endpoint where applicable (move the "created_at DESC" text into the endpoint
operation descriptions that actually use that default). Ensure the `sort` schema
description stays generic (e.g., "Optional: sort results. Array for future
extensibility; max 1 via protovalidate for now.") and update endpoint docs to
state their specific fallback behavior.
- Around line 1088-1102: The SortField schema currently allows a free-form
string for the field property (policy.SortField.field); change this to use a
resource-specific enum reference instead of type: string — either (a) define
per-resource enum schemas (e.g., policy.UserSortFieldFields,
policy.ProjectSortFieldFields) and replace field's type with $ref to the
appropriate enum, or (b) replace policy.SortField with a oneOf/anyOf that
references resource-specific SortField schemas so each resource's sortable field
names are strictly typed; update any request/response schemas that reference
policy.SortField to use the correct resource-specific SortField schema.

In `@docs/openapi/policy/namespaces/namespaces.openapi.yaml`:
- Around line 695-703: Clarify in the ListNamespacesRequest OpenAPI description
which sort mechanism wins: update the documentation for the resource-specific
"sort" field (items $ref '#/components/schemas/policy.SortNamespacesType' or
mention SortNamespacesType enum) to state that it takes precedence over the
generic pagination.sort (policy.SortField) and recommend clients use the
strongly-typed "sort" for namespace results; additionally add a note suggesting
deprecating pagination.sort for this endpoint (or explicitly document both if
deprecation is deferred) so consumers are not confused about precedence between
ListNamespacesRequest.pagination.sort and the endpoint-level sort field.

In `@service/policy/db/namespaces.sql.go`:
- Around line 202-213: The ORDER BY ends with a non-unique tie-breaker
(ns.created_at DESC) causing unstable pagination; update the SQL in the ORDER BY
clause to append a unique deterministic tie-breaker such as ns.id (e.g., add ",
ns.id ASC" after ns.created_at DESC or otherwise ensure ns.id is the final
ordering key) so rows with identical sort keys are ordered consistently; apply
this change in the query that generates namespaces (modify the ORDER BY in the
namespaces SQL query) and then regenerate sqlc so the updated statement lands in
service/policy/db/namespaces.sql.go.

In `@service/policy/db/queries/namespaces.sql`:
- Around line 16-25: The ORDER BY clause must include a deterministic
tie-breaker to prevent duplicate/skip across pages when created_at/updated_at
collide; update the ORDER BY in the namespaces query to append ns.id as the
final sort key (after the existing conditional cases and fallback ns.created_at
DESC) so that every ordering is stable, ensuring you reference ns.id alongside
the existing `@sort_field/`@sort_direction logic in the ORDER BY expression.

---

Outside diff comments:
In `@docs/grpc/index.html`:
- Around line 12352-12484: Update the source protobuf comments to clearly
document the ListNamespacesRequest.sort contract: in the comment for the
ListNamespacesRequest.sort field and on the NamespacesSort message, state that
although the field is declared repeated it is optional and only the first
element is applied (i.e., single-field sorting / default behavior), or define
the explicit multi-key merge semantics if multi-key sorting is supported;
mention the default sort if none provided and reference SortNamespacesType and
SortDirection. After changing the comments on ListNamespacesRequest.sort and
NamespacesSort, regenerate the HTML docs so the updated contract appears in the
generated page.
- Around line 7401-7482: The generated HTML incorrectly documents a non-existent
PageRequest.sort and a global SortField message; remove the PageRequest.sort
entry and the SortField section/toc entries, and instead ensure any sorting docs
reference the request-scoped sort types (e.g., ListNamespacesRequest ->
NamespacesSort) and the shared enum SortDirection only where actually used;
update/remove duplicated SortDirection TOC/section so SortDirection appears once
and is linked from request-specific sort fields rather than from PageRequest or
a global SortField.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: af958750-fcd6-4d3a-b700-94e241bded6a

📥 Commits

Reviewing files that changed from the base of the PR and between a9d66ae and c8bb6d0.

⛔ Files ignored due to path filters (2)

• protocol/go/policy/namespaces/namespaces.pb.go is excluded by !**/*.pb.go
• protocol/go/policy/selectors.pb.go is excluded by !**/*.pb.go

📒 Files selected for processing (19)

• docs/grpc/index.html
• docs/openapi/policy/actions/actions.openapi.yaml
• docs/openapi/policy/attributes/attributes.openapi.yaml
• docs/openapi/policy/kasregistry/key_access_server_registry.openapi.yaml
• docs/openapi/policy/keymanagement/key_management.openapi.yaml
• docs/openapi/policy/namespaces/namespaces.openapi.yaml
• docs/openapi/policy/obligations/obligations.openapi.yaml
• docs/openapi/policy/registeredresources/registered_resources.openapi.yaml
• docs/openapi/policy/resourcemapping/resource_mapping.openapi.yaml
• docs/openapi/policy/selectors.openapi.yaml
• docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml
• service/integration/namespaces_test.go
• service/policy/db/namespaces.go
• service/policy/db/namespaces.sql.go
• service/policy/db/queries/namespaces.sql
• service/policy/db/utils.go
• service/policy/db/utils_test.go
• service/policy/namespaces/namespaces.proto
• service/policy/selectors.proto

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	183.783619ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	97.655581ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	415.564687ms
Throughput	240.64 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	42.398585152s
Average Latency	421.770284ms
Throughput	117.93 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ java-pull-3192
✅ go-v0.9.0
✅ js-pull-3192
✅ java-v0.9.0
✅ js-v0.9.0
test-cases-mapping-report
bats-test-results
cukes-report
opentdfplatformR0J5SV.dockerbuild

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/grpc/index.html`:
- Around line 12275-12280: Update the documentation/source proto comments for
the Namespaces RPC so the repeated field "sort" (type
policy.namespaces.NamespacesSort) clearly documents that only a single sort
entry is honored and that if none is provided the server falls back to ordering
by created_at DESC; change the comment block for the "sort" field in the
relevant .proto or template to state "Only the first sort entry is used; if
omitted the server orders by created_at DESC" and then regenerate the HTML docs
so the change appears throughout the generated pages (including the other
referenced ranges).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 60e06a80-d6ad-4e67-8a23-b6d075bc7647

📥 Commits

Reviewing files that changed from the base of the PR and between c8bb6d0 and 74ff26e.

📒 Files selected for processing (3)

• docs/grpc/index.html
• docs/openapi/policy/namespaces/namespaces.openapi.yaml
• docs/openapi/policy/selectors.openapi.yaml

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	203.991844ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	95.900084ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	407.738441ms
Throughput	245.26 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	44.368611861s
Average Latency	442.468712ms
Throughput	112.69 requests/second

[github-actions]

X-Test Results

✅ go-pull-3192
✅ go-v0.9.0
✅ java-pull-3192
✅ js-pull-3192
✅ java-v0.9.0
✅ js-v0.9.0
test-cases-mapping-report
bats-test-results
cukes-report
opentdfplatformZZJI1I.dockerbuild