feat(policy): hydrate resource_mappings on ListAttributes values

[KevLehman]

Summary

• policy.attributes.AttributesService/ListAttributes now returns resource_mappings on every Value, matching the shape already produced by GetAttributeValuesByFqns and already advertised in the generated OpenAPI spec.
• The SQL change extends listAttributesDetail with a pre-aggregated value_resource_mappings CTE (same pattern used by listAttributesByDefOrValueFqns), so mappings are hydrated without introducing row-explosion through the main GROUP BY.
• No proto change. No new request toggle. No behavior change for callers that ignore the new field.

Before / after

Before (trimmed):

{
  "id": "…",
  "value": "topsecret",
  "fqn": "https://demo.com/attr/classification/value/topsecret",
  "active": true
}

After:

{
  "id": "…",
  "value": "topsecret",
  "fqn": "https://demo.com/attr/classification/value/topsecret",
  "active": true,
  "resourceMappings": [
    { "id": "…", "terms": ["ts", "top-secret", "top_secret"] }
  ]
}

Reproduction:

grpcurl -plaintext -d '{"pagination":{"limit":500}}' \
  localhost:8080 policy.attributes.AttributesService/ListAttributes

Why

Clients that need label/term data (UI pickers, classifiers, policy editors) currently have to enumerate FQNs via ListAttributes and then batch‑hydrate them through GetAttributeValuesByFqns (250 FQN cap per call). The OpenAPI spec already documents resourceMappings on ListAttributes, so the current server response is inconsistent with the schema clients read. Hydrating directly collapses the two round trips into one.

Implementation notes

• listAttributesDetail gets a new CTE (value_resource_mappings) keyed by attribute_value_id, producing a JSON_AGG of {id, terms, group} per value — exactly the shape listAttributesByDefOrValueFqns emits.
• The CTE is joined once against the flattened avt subquery by av.id. Row count per attribute definition is unchanged (one row per value), so JSON_AGG … FILTER (WHERE avt.id IS NOT NULL) and the GROUP BY ad.id, n.name, fqns.fqn + COUNT(*) OVER() pagination continue to behave the same.
• Value already declares repeated ResourceMapping resource_mappings = 10;, so the Go DAO (attributesValuesProtojson → protojson.Unmarshal) picks up the new field automatically. No scanning code changed.
• GetAttribute is intentionally out of scope — it uses the separate getAttribute query and was left unchanged.

Out of scope

• subject_mappings / kas_keys / grants / obligations / value-level metadata hydration on ListAttributes. Each is its own JOIN and its own tradeoff, tracked as follow-ups.

Test plan

• go build ./service/...
• go vet ./service/policy/... ./service/integration/...
• golangci-lint run -c .golangci.yaml ./policy/db/... — 0 issues
• go test ./service/policy/... — 761 passed
• go test -run '^TestAttributesSuite$' ./service/integration/... — 92 passed (includes new Test_ListAttributes_HydratesResourceMappings)
• go test -run '^TestAttributeFqnSuite$' ./service/integration/... — 38 passed
• go test -run '^TestResourceMappingsSuite$|^TestAttributeValuesSuite$|^TestNamespacesSuite$' ./service/integration/... — 161 passed

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Attribute listings now include resource mapping information for each attribute value.

• Tests

  • Added integration test verifying resource mappings are properly populated for attribute values, including both grouped and ungrouped mappings.

[coderabbitai]

Warning

Rate limit exceeded

@KevLehman has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 42 minutes and 51 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 42 minutes and 51 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6d2563d1-4eac-4783-a9d5-b75c06d090b8

📥 Commits

Reviewing files that changed from the base of the PR and between 378bab0 and 98ccd6d.

📒 Files selected for processing (2)

• service/policy/db/attributes.sql.go
• service/policy/db/queries/attributes.sql

📝 Walkthrough

Walkthrough

Adds support for hydrating resource_mappings data when listing attributes. A new SQL CTE pre-aggregates resource mappings per attribute value, the Go code generation is updated to process this additional field, and a test verifies mapped and unmapped values are correctly returned with their respective resource mappings.

Changes

Cohort / File(s)	Summary
Database Query Enhancement service/policy/db/queries/attributes.sql, service/policy/db/attributes.sql.go	Added a value_resource_mappings CTE that aggregates resource mappings and groups into JSON per attribute value, with LEFT JOIN integration into the main listAttributesDetail query and updated sqlc-generated code.
Integration Test service/integration/attributes_test.go	New test for ListAttributes that verifies resource mappings are correctly hydrated on returned attribute values, including mappings with and without group associations.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A mapping most fine, in JSON array neat,
CTEs hop along, making data complete,
Resources now grouped, or alone as they please,
Hydrated with care, we're sure to appease! 🥕

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main change: adding resource_mappings hydration to ListAttributes values.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[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 `@service/policy/db/queries/attributes.sql`:
- Around line 6-26: The value_resource_mappings CTE currently aggregates the
entire resource_mappings table (resource_mappings rm) which can be wasteful; to
scope it, join or filter rm by only the attribute_value_id /
attribute_definition IDs used by the outer query (e.g., restrict rm via the avt
subquery or by joining against attribute_definitions referenced later) so the
CTE only aggregates mappings for the selected
attribute_definitions/attribute_values instead of the whole table; adjust the
FROM/JOIN in value_resource_mappings to reference avt or the
attribute_definition id set so the GROUP BY and produced res_maps remain
identical but are computed only for relevant rows.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 608783a4-6e12-49e8-ba21-57b0c1bd889e

📥 Commits

Reviewing files that changed from the base of the PR and between 0382742 and 378bab0.

📒 Files selected for processing (3)

• service/integration/attributes_test.go
• service/policy/db/attributes.sql.go
• service/policy/db/queries/attributes.sql

[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 updates the ListAttributes service to automatically hydrate resource_mappings for attribute values. By modifying the underlying SQL query to include a pre-aggregated CTE, the change allows clients to retrieve necessary label and term data in a single round trip, eliminating the need for subsequent batch-hydration calls and ensuring consistency with the documented API schema.

Highlights

• API Response Enhancement: The ListAttributes endpoint now includes resource_mappings in its response, aligning the implementation with the existing OpenAPI specification.
• Database Optimization: Updated the listAttributesDetail SQL query to use a CTE for pre-aggregating resource mappings, preventing row-explosion issues during data retrieval.
• Integration Testing: Added a new integration test, Test_ListAttributes_HydratesResourceMappings, to verify that resource mappings are correctly populated for attribute values.

🧠 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.

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.

---

The query was slow and quite lean, Now mappings are clearly seen. With a CTE join, We save every coin, And keep the API pristine.

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. ↩

[gemini-code-assist]

Code Review

This pull request updates the listAttributesDetail SQL query to include resource mapping data for attribute values and adds an integration test to verify this hydration. The review feedback identifies a significant performance concern regarding the use of a global Common Table Expression (CTE) for aggregating resource mappings, which could lead to degradation as the database grows. It is recommended to replace the global CTE with a correlated subquery within the JSON construction to ensure aggregation only occurs for the filtered results.

[jakedoublev]

@KevLehman Thanks so much for contributing! We discussed as a team and, while this may be a useful thing to have back from ListAttributes, we want to avoid additional response overhead since this RPC is on a lot of hot paths. We are also considering either more granular APIs for specific use cases or possible selectors/expanders, which both have their own tradeoffs. All of that said, we can't quite move forward with this at the moment, but we appreciate the idea and will definitely keep it in mind.

[KevLehman]

Hey, thanks for checking.

Would you be open to do this change on the API only? when calling v2.ListAttributes?

That way, we would have the information needed without having to do a 2nd (+n) paginated call to ListResourceMappings and map locally

[marythought]

Hi @KevLehman — thanks again for the PR!

Of the use cases you list (UI pickers, classifiers, policy editors), the classifier path is exactly what the Virtru Data Security Platform Tagging Service is built for. Instead of clients pulling label/term data and resolving locally, you send content (or already-extracted tags) to the Tagging Service and get back normalized attribute FQNs — synonym dictionary and resource mappings stay server-side, no client enumeration needed.

Hand-rolled in client:

1. Enumerate via ListAttributes / GetAttributeValuesByFqns (and pay the 250-FQN cap)
2. Resolve label → FQN locally
3. Call GetDecisions with FQNs

With the Tagging Service:

1. Send content (or tags) → Tagging Service returns FQNs
2. Call GetDecisions with FQNs

One thing worth calling out: keeping that logic server-side means changes to the synonym dictionary, resource mappings, or extraction rules land as Tagging Service config inside DSP — no client redeploy, no SDK upgrade, and no version skew between what your client thinks the labels are and what the policy says they are.

We're also actively working on an SDK helper that wraps (identity + content) → allowed/denied into a single call — tag normalization and decision in one step. Happy to share more once it's a bit further along!

Glad to walk through the Tagging Service fit if useful.

-- Mary