fix(policy): wrap SQL optional param type casts in null checks

[alkalescent]

Proposed Changes

• PostgreSQL's query optimizer evaluates conditions for WHERE clauses in any order, so we must wrap optional parameter type casts in null checks to ensure expressions are safe.

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

[gemini-code-assist]

Summary of Changes

Hello @alkalescent, 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 addresses a critical issue in PostgreSQL queries where the database's query optimizer could attempt to type cast null values for optional parameters, leading to execution errors. The changes introduce a robust pattern using params CTEs to ensure that type casts are only applied to non-null values, significantly improving the stability and reliability of database operations involving optional inputs.

Highlights

• SQL Query Refactoring: Introduced params Common Table Expressions (CTEs) in several SQL queries to centralize the handling and casting of optional parameters.
• Enhanced Null Safety: Implemented explicit null checks before type casting optional parameters within SQL queries, preventing potential runtime errors in PostgreSQL caused by its query optimizer evaluating conditions in an unpredictable order.
• Parameter Order Alignment: Adjusted the order of parameters passed to the listObligationTriggers and listObligations Go functions to correctly align with the refactored SQL queries, where pagination parameters are now passed before namespace-related parameters.

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

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

Nulls cast to UUID, Postgres optimizer's trick, Safe checks now prevent.

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 addresses a critical issue in several SQL queries where casting optional parameters to UUID could cause runtime errors if an empty string was provided. The fix, which involves using a params Common Table Expression (CTE) to safely handle type casting, is well-implemented and has been applied consistently across all relevant queries. This not only resolves the bug but also improves the overall readability and robustness of the SQL code. The changes in the generated Go files are consistent with the SQL modifications. However, the pull request would be strengthened by adding integration tests that specifically target the fixed vulnerability, for instance by passing empty strings for optional UUID parameters. This would help prevent future regressions.

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

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

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

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	367.714901ms
Throughput	271.95 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	38.144411549s
Average Latency	380.086419ms
Throughput	131.08 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	26.709256709s
Average Latency	266.057587ms
Throughput	187.20 requests/second

[github-actions]

X-Test Results

opentdfplatform3PKRTY.dockerbuild
cukes-report
✅ js-v0.4.34
✅ java-v0.4.34
✅ go-v0.4.34
bats-test-results
test-cases-mapping-report
✅ js-pull-2977
✅ java-pull-2977
✅ go-pull-2977

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

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

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

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	380.371556ms
Throughput	262.90 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	39.366371073s
Average Latency	391.718485ms
Throughput	127.01 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	27.876553682s
Average Latency	277.931425ms
Throughput	179.36 requests/second

[github-actions]

X-Test Results

opentdfplatformSJZQRX.dockerbuild
✅ java-v0.4.34
✅ js-v0.4.34
cukes-report
✅ go-v0.4.34
bats-test-results
test-cases-mapping-report
✅ js-pull-2977
✅ java-pull-2977
✅ go-pull-2977

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

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

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

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	358.772538ms
Throughput	278.73 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	38.230269459s
Average Latency	379.656866ms
Throughput	130.79 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	27.263950858s
Average Latency	271.615243ms
Throughput	183.39 requests/second

[github-actions]

X-Test Results

opentdfplatformJHHLUL.dockerbuild
✅ java-v0.4.34
cukes-report
✅ js-v0.4.34
✅ go-v0.4.34
bats-test-results
test-cases-mapping-report
✅ js-pull-2977
✅ java-pull-2977
✅ go-pull-2977

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

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

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

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	367.767044ms
Throughput	271.91 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	38.476140068s
Average Latency	382.602625ms
Throughput	129.95 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	27.760720966s
Average Latency	276.504494ms
Throughput	180.11 requests/second

[github-actions]

X-Test Results

opentdfplatformZBTC0P.dockerbuild
✅ java-v0.4.34
✅ js-v0.4.34
cukes-report
✅ go-v0.4.34
bats-test-results
test-cases-mapping-report
✅ js-pull-2977
✅ java-pull-2977
✅ go-pull-2977

[alkalescent]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses a potential issue with PostgreSQL's query optimizer by wrapping optional parameter type casts in null checks using Common Table Expressions (CTEs). The changes are applied consistently across numerous SQL queries and their corresponding generated Go files. The use of a params CTE to handle optional parameters is a robust solution to prevent optimizer-related errors. Additionally, new integration tests have been added to validate the correctness of these changes, covering various parameter combinations and ensuring the endpoints continue to function as expected. The code modifications are well-executed and the added tests provide confidence in the fix. The pull request is well-structured and the changes are approved.