Int test fail paths

[ginaxu1]

Summary

Added tests/integration/failure_paths_test.go with 6 failure path tests:

1. TestFailurePath_PDP_ServiceUnavailable

• Scenario: Policy Decision Point service is down/unavailable
• Expected: GraphQL query fails with PDP_ERROR, SERVICE_UNAVAILABLE, or INTERNAL_ERROR
• Method: Pauses the PDP Docker container during the test

2. TestFailurePath_PDP_Succeeds_ConsentNotGranted

• Scenario: PDP succeeds (policy metadata exists, app in allowlist) but consent is pending (not approved)
• Expected: GraphQL query fails with CE_ERROR or CE_NOT_APPROVED
• Method: Creates consent but leaves it in "pending" status

3. TestFailurePath_PDP_Succeeds_ConsentExpired

• Scenario: PDP succeeds but consent grant has expired (grant_expires_at is in the past)
• Expected: GraphQL query fails with CE_ERROR, CE_EXPIRED, or CE_NOT_APPROVED
• Method: Manually sets grant_expires_at to a past time in the database

4. TestFailurePath_PDP_AuthorizationFailure

• Scenario: Policy metadata exists but app is NOT in allowlist
• Expected: GraphQL query fails with PDP_ERROR or PDP_NOT_ALLOWED
• Method: Creates policy metadata but intentionally skips adding app to allowlist

5. TestFailurePath_ConsentEngine_ServiceUnavailable

• Scenario: Consent Engine service is down/unavailable
• Expected: GraphQL query fails with CE_ERROR, SERVICE_UNAVAILABLE, or INTERNAL_ERROR
• Method: Pauses the Consent Engine Docker container during the test

6. TestFailurePath_PDP_Succeeds_ConsentRejected

• Scenario: PDP succeeds but consent status is "rejected"
• Expected: GraphQL query fails with CE_ERROR or CE_NOT_APPROVED
• Method: Manually sets consent status to "rejected" in the database

7. TestFailurePath_Provider_ServiceUnavailable

• Scenario: Provider data source is unavailable (documented behavior)
• Expected: GraphQL query may fail with provider errors or return partial data
• Note: This test documents expected behavior; actual provider failures depend on external services

[gemini-code-assist]

Summary of Changes

Hello @ginaxu1, 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 introduces several enhancements and new tests to improve the reliability, security, and maintainability of the consent engine and policy decision point services. It includes documentation for the release process, dependency cleanup, comprehensive unit and integration tests, code validation, and improved test infrastructure.

Highlights

• Release Guide: Adds a new RELEASE.md file to document the release process, including how to trigger automated releases via GitHub Actions and manual release instructions.
• Dependency Management: Removes unused dependencies (go-sqlmock, sqlstruct) from consent-engine/go.mod and go.sum.
• Unit Testing: Introduces new unit tests for database configuration (database_test.go), JWT authentication middleware (auth_test.go), CORS middleware (cors_test.go), consent models (consent_test.go), HTTP response utilities (http_response_test.go), and V1 router (router_test.go).
• Integration Testing: Adds new integration tests for Consent Engine and Policy Decision Point database connections, and moves database connection tests from unit tests to integration tests.
• Code Validation: Adds validation for required fields in the GetPolicyDecision handler.
• Test Helpers: Introduces new test helpers for setting up PostgreSQL test databases and managing environment variables.
• Failure Path Testing: Adds new failure path tests to verify the system handles scenarios such as PDP service unavailability, consent not granted, consent expired, PDP authorization failure, and Consent Engine service unavailability.
• Test Organization: Refactors existing tests to use SQLite in-memory databases for unit tests and PostgreSQL for integration tests.

🧠 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: .github/workflows/** (2)
  • .github/workflows/RELEASE_GUIDE.md
  • .github/workflows/release.yml

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.

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 introduces a comprehensive suite of new integration tests across the Consent Engine and Policy Decision Point services, significantly enhancing the test coverage and reliability of the system. The tests cover various success and failure paths, including service unavailability, consent status changes, and authorization failures. Additionally, database connection helpers have been refactored and improved, and a critical security measure (isValidDBName) has been added to prevent SQL injection in test database creation. Documentation for the integration test structure has also been updated. Overall, these changes represent a substantial improvement in the project's testing infrastructure and robustness.

I am having trouble creating individual review comments. Click here to see my feedback.

exchange/policy-decision-point/v1/testhelpers/helpers.go (72-75)

The isValidDBName function is a critical security addition. It helps prevent SQL injection vulnerabilities when dynamically creating database names in PostgreSQL, especially in test environments where inputs might be less controlled. This is an excellent practice to ensure the integrity of database operations.

tests/integration/policy/policy_test.go (192-220)

The comment correctly identifies that the handler currently doesn't validate an empty schemaId. Adding this validation directly in the handler would improve API robustness by catching invalid requests earlier and providing clearer error messages to clients. This would prevent the request from proceeding to the service layer with potentially invalid data.

docs/RELEASE.md (12)

It's good practice to use a placeholder for the version number in documentation examples to make it clear that v1.0.0 is an example and not a literal value to be used. This improves the clarity and reusability of the instructions.

git tag <VERSION>

docs/RELEASE.md (23)

Similar to the tag example, using a placeholder for the version in the manual release instructions would make it clearer that v1.0.0 is an example. This helps users understand they need to substitute the actual version.

Go to **Actions** → **Release - Build and Publish All Services** → **Run workflow** → Enter version (e.g., `<VERSION>`)

docs/RELEASE.md (42)

Using a placeholder for the version in the verification command makes the example more generic and useful for future releases. This indicates that the user should replace <VERSION> with the actual release version.

docker pull ghcr.io/opendif/opendif-core/portal-backend:<VERSION>

[sthanikan2000]

Actually Integration tests workflow should be triggered in the GitHub Actions. But it didn't . So triggered it manually and it fails. Check at https://github.com/OpenDIF/opendif-core/actions/runs/21288083314

Fix the issues. Your test cases are fine. Also If you can make changes to the integration-workflow code trigger workflow, that will be also fine