Feat/runtime upgrades #1218

jusdino · 2025-11-20T22:18:48Z

Description List

Upgraded Python lambdas and pipelines to 3.14, excepting purchases lambda, which is held back at 3.12
Upgraded NodeJS lambdas and pipelines to 24
Upgraded libraries
Addressed/tested aws-cdk bugfix that introduced a DynamoDB resource policy statement that was previously missing, due to the bug

Testing List

Ran investigation smoke test to verify Python API / Node email function
Tested SSN UI features and SSN table backups, to verify continued function after introduction of missing policy statement
Deployed and loaded UI to verify CSP lambda function
Code review
Deploy via pipeline to test, to verify pipeline compatibility

Closes #1216

Summary by CodeRabbit

New Features
- Added signature-auth examples and notes documenting the Purchases service running in its own Python 3.12 environment
Bug Fixes
- Corrected ISO8601 timestamp formatting in test utilities
Documentation
- Updated Node.js/Python prerequisite versions and added convenience scripts and usage notes
Chores
- Upgraded CI/tooling targets (Python → 3.14, Node → 24.x) and bumped many dependency pins
- Added private key gitignore patterns; removed an unused lambda dependency
Tests
- Refactored tests and assertions for improved maintainability

_{✏️ Tip: You can customize this high-level summary in your review settings.}

coderabbitai · 2025-11-20T22:19:00Z

Walkthrough

Updates CI action versions and runtime inputs (Python → 3.14, Node → 24.x), isolates the purchases lambda to a Python 3.12 workflow and separate dependency handling, bumps many dependency pins, extracts a signing helper, tightens SSN table policy handling and tests, and updates related docs and snapshots.

Changes

Cohort / File(s)	Summary
Workflows (CI/CD) `\.github/workflows/check-compact-connect-ui-app.yml`, `\.github/workflows/check-compact-connect.yml`, `\.github/workflows/check-common-cdk.yml`, `\.github/workflows/*`	Bumped GitHub Action usages (checkout/setup-python/setup-node) and runtime inputs (Python 3.12→3.14, Node 22.x→24.x); added a TestAndLintPurchases job to run purchases checks under Python 3.12.
CDK & Lambda Runtimes `backend/compact-connect/common_constructs/.py`, `backend/compact-connect/stacks/...`, `backend/compact-connect-ui-app/stacks/...`, `backend/compact-connect-ui-app/tests/resources/snapshots/`	Updated default runtimes and resource Runtime values: Node.js 22.x → 24.x and Python 3.13 → 3.14 (constructor defaults, stack resources, and snapshots).
Purchases Lambda Isolation & Scripts `backend/compact-connect/bin/compile_requirements.sh`, `backend/compact-connect/bin/sync_deps.sh`, `backend/compact-connect/bin/run_python_tests.py`, `backend/compact-connect/lambdas/python/purchases/*`	Excluded purchases lambda from shared compile/sync/test flows; added comments explaining separate Python 3.12 environment; updated purchases requirements files, added `.coveragerc`, and added dev deps in `requirements-dev.in`.
Requirements / Dependency Pins `backend/compact-connect/*/requirements.txt`, `backend/compact-connect-ui-app/requirements.txt`, `backend/compact-connect/requirements.txt`	Bumped many dependency pins and updated autogenerated headers to Python 3.14 (most) or 3.12 for purchases; updated CDK/tooling pins (aws-cdk-lib, jsii, constructs, etc.).
Tests & Snapshots `backend/compact-connect/tests/*`, `backend/compact-connect-ui-app/tests/resources/snapshots/`	Adjusted tests to expect Python 3.14 runtimes; refreshed snapshot Lambda runtimes/refs (nodejs22.x → nodejs24.x) and CSPFunction version refs; refactored SSN table tests to dynamic has_resource assertions.
Sign Request Refactor `backend/compact-connect/lambdas/python/common/common_test/sign_request.py`, `backend/compact-connect/docs/signature_auth_examples.txt`, `backend/compact-connect/docs/client_signature_auth.md`	Extracted `get_string_to_sign(...)` helper and updated `sign_request` to use it; added signature examples file and updated docs to reference both example files.
SSN Table Policy & Tests `backend/compact-connect/stacks/persistent_stack/ssn_table.py`, `backend/compact-connect/tests/app/base.py`, `backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json`	Removed some actions from deny list and replaced dynamic table name usage with a constant to avoid circular refs; updated tests to validate via parameterized resource assertions; snapshot policy file removed.
Docs & Miscellaneous `backend/compact-connect/README.md`, `backend/compact-connect-ui-app/lambdas/nodejs/README.md`, `backend/compact-connect/app_clients/.gitignore`, `backend/compact-connect-ui-app/lambdas/nodejs/package.json`	Updated prerequisite Node/Python versions, added `.pem`/`.pub` to gitignore, removed `aws-lambda` from package.json, and added signature examples and README references.

Sequence Diagram(s)

sequenceDiagram
    participant Caller as Caller
    participant SignReq as sign_request()
    participant Helper as get_string_to_sign()
    participant Crypto as HMAC / Crypto

    Caller->>SignReq: provide method, path, query, timestamp, nonce, key_id
    SignReq->>Helper: get_string_to_sign(method, path, query, timestamp, nonce, key_id)
    Note over Helper: sort & URL-encode query params
    Helper-->>SignReq: canonical string to sign
    SignReq->>Crypto: compute signature (HMAC / key)
    Crypto-->>SignReq: base64 signature
    SignReq-->>Caller: headers (X-Signature, X-Timestamp, X-Nonce, X-Key-Id, ...)

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Areas needing focused review:
- Purchases lambda isolation: CI job, compile/sync scripts, and purchases requirements/coveragerc.
- SSN table policy changes and ARN constant substitution—verify intended security posture and template generation.
- Test refactor in tests/app/base.py — ensure assertions remain equivalent in backup-enabled/disabled contexts.
- Broad dependency bumps—spot-check compatibility for CDK, boto3, powertools, and other core packages.
- get_string_to_sign extraction — ensure canonicalization matches prior behavior exactly.

Possibly related PRs

set nodejs version used by CDK pipeline #754 — modifies CodeBuild synth buildspec/runtime versions (related to frontend pipeline runtime changes).
Add ecdsa auth to state api #1005 — touches sign_request refactor and signing helper changes.
Feat/data retention backup #907 — alters dependency management scripts (compile_requirements.sh, sync_deps.sh), overlapping purchases isolation changes.

Suggested reviewers

jlkravitz
landonshumway-ia
isabeleliassen

"🐰 I hopped through runtimes, tidy and spry,
Python leapt forward, Node reached the sky,
Purchases now rest in their own cozy nest,
Signatures hum from a helper neatly dressed,
Tests and policies pruned — a joyful little hop and a rest."

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 59.26% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title 'Feat/runtime upgrades' is clear, specific, and directly reflects the main change—upgrading Python and Node.js runtimes across lambdas and pipelines.
Description check	✅ Passed	Description covers key changes (Python to 3.14, Node to 24, library upgrades) and testing performed. Partially follows template but lacks complete Requirements List section, though key details are present.
Linked Issues check	✅ Passed	Pull request addresses all requirements from #1216: Python runtime upgrades completed (3.14 for most, 3.12 for purchases), Node upgrades to 24, dependencies upgraded, and DynamoDB policy bugfix addressed.
Out of Scope Changes check	✅ Passed	All changes align with runtime upgrade objectives from #1216. Updates to GitHub Actions versions, workflow files, documentation, dependency files, and runtime configurations are all in-scope for the runtime upgrade initiative.

✨ Finishing touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 92222b4 and 68f813e.

📒 Files selected for processing (1)

backend/compact-connect/README.md (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

backend/compact-connect/README.md

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

GitHub Check: TestApp
GitHub Check: TestApp

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

Provide your own instructions using the high_level_summary_instructions setting.
Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

📝 Description — Summarize the main change in 50–60 words, explaining what was done.

📓 References — List relevant issues, discussions, documentation, or related PRs.

📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.

📊 Contributor Summary — Include a Markdown table showing contributions:
| Contributor | Lines Added | Lines Removed | Files Changed |

✔️ Additional Notes — Add any extra reviewer context.
Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

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

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

coderabbitai

Actionable comments posted: 2

♻️ Duplicate comments (3)

backend/compact-connect/tests/common_constructs/test_queue_event_listener.py (1)

28-28: Runtime upgrade looks good.

The runtime upgrade is consistent with the project-wide Python 3.14 migration.

backend/compact-connect/tests/common_constructs/test_queued_lambda_processor.py (1)

24-24: LGTM!

The runtime upgrade is consistent with the project-wide Python 3.14 migration.

backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py (1)

46-46: LGTM!

The compatible_runtimes update is consistent with the Python 3.14 migration.

🧹 Nitpick comments (1)

backend/compact-connect/lambdas/python/purchases/requirements.txt (1)

2-9: Verify the pip-compile workflow for purchases lambda.

The autogenerated header indicates pip-compile was invoked with requirements.in (line 5) rather than the full path lambdas/python/purchases/requirements.in that other lambdas use. This suggests the file was generated by running pip-compile from within the lambdas/python/purchases/ directory rather than from the repository root.

Since compile_requirements.sh now has purchases lambda lines commented out, confirm this manual workflow from within the purchases directory is the intended approach for maintaining these dependencies going forward. If so, consider documenting this in the purchases lambda's README or the main README.

Based on learnings

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ee3e30 and a8c2f7a.

⛔ Files ignored due to path filters (1)

backend/compact-connect-ui-app/lambdas/nodejs/yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (52)

.github/workflows/check-compact-connect-ui-app.yml (2 hunks)
.github/workflows/check-compact-connect.yml (2 hunks)
backend/compact-connect-ui-app/lambdas/nodejs/README.md (1 hunks)
backend/compact-connect-ui-app/lambdas/nodejs/cloudfront-csp/README.md (1 hunks)
backend/compact-connect-ui-app/lambdas/nodejs/package.json (0 hunks)
backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py (1 hunks)
backend/compact-connect/README.md (2 hunks)
backend/compact-connect/app_clients/.gitignore (1 hunks)
backend/compact-connect/bin/compile_requirements.sh (1 hunks)
backend/compact-connect/bin/sync_deps.sh (1 hunks)
backend/compact-connect/common_constructs/nodejs_function.py (1 hunks)
backend/compact-connect/common_constructs/python_function.py (1 hunks)
backend/compact-connect/common_constructs/user_pool.py (1 hunks)
backend/compact-connect/docs/client_signature_auth.md (1 hunks)
backend/compact-connect/docs/signature_auth_examples.txt (1 hunks)
backend/compact-connect/lambdas/nodejs/README.md (1 hunks)
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/cognito-backup/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/common/cc_common/data_model/transaction_client.py (1 hunks)
backend/compact-connect/lambdas/python/common/common_test/sign_request.py (2 hunks)
backend/compact-connect/lambdas/python/common/requirements-dev.txt (11 hunks)
backend/compact-connect/lambdas/python/common/requirements.txt (2 hunks)
backend/compact-connect/lambdas/python/common/tests/function/test_data_model/test_transaction_client.py (1 hunks)
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/custom-resources/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/data-events/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/data-events/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt (4 hunks)
backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt (7 hunks)
backend/compact-connect/lambdas/python/purchases/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt (2 hunks)
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements.txt (1 hunks)
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt (4 hunks)
backend/compact-connect/lambdas/python/staff-users/requirements.txt (1 hunks)
backend/compact-connect/pipeline/backend_pipeline.py (1 hunks)
backend/compact-connect/requirements-dev.txt (4 hunks)
backend/compact-connect/requirements.txt (4 hunks)
backend/compact-connect/stacks/api_lambda_stack/provider_users.py (1 hunks)
backend/compact-connect/stacks/persistent_stack/__init__.py (1 hunks)
backend/compact-connect/stacks/persistent_stack/ssn_table.py (1 hunks)
backend/compact-connect/tests/app/base.py (1 hunks)
backend/compact-connect/tests/app/test_pipeline.py (1 hunks)
backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py (2 hunks)
backend/compact-connect/tests/common_constructs/test_data_migration.py (1 hunks)
backend/compact-connect/tests/common_constructs/test_queue_event_listener.py (1 hunks)
backend/compact-connect/tests/common_constructs/test_queued_lambda_processor.py (1 hunks)
backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json (1 hunks)

💤 Files with no reviewable changes (1)

backend/compact-connect-ui-app/lambdas/nodejs/package.json

🧰 Additional context used

🧠 Learnings (19)

📓 Common learnings

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/common/requirements.txt:7-0
Timestamp: 2025-07-21T20:40:56.491Z
Learning: In CompactConnect, there is only one lambda layer in use for Python lambdas, and this single layer manages the versions of aws-lambda-powertools, boto3, and botocore dependencies. This eliminates concerns about version skew across multiple lambda layers since all Python lambdas share the same dependency management through this single layer.

📚 Learning: 2025-07-22T03:52:25.934Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Applied to files:

backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt
backend/compact-connect/tests/common_constructs/test_queue_event_listener.py
backend/compact-connect/lambdas/python/purchases/requirements.txt
backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py
backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt
backend/compact-connect/lambdas/python/data-events/requirements-dev.txt
backend/compact-connect/stacks/api_lambda_stack/provider_users.py
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt
backend/compact-connect/requirements.txt
backend/compact-connect/bin/sync_deps.sh
backend/compact-connect/lambdas/python/staff-users/requirements.txt
backend/compact-connect/stacks/persistent_stack/__init__.py
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements.txt
backend/compact-connect/lambdas/python/custom-resources/requirements.txt
backend/compact-connect/lambdas/python/common/requirements.txt
backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py
backend/compact-connect/lambdas/python/data-events/requirements.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt
backend/compact-connect/pipeline/backend_pipeline.py
backend/compact-connect/bin/compile_requirements.sh
backend/compact-connect/README.md
backend/compact-connect/tests/app/test_pipeline.py
backend/compact-connect/tests/common_constructs/test_queued_lambda_processor.py
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt
backend/compact-connect/requirements-dev.txt
backend/compact-connect/lambdas/python/common/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-08-12T19:49:48.235Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt:1-6
Timestamp: 2025-08-12T19:49:48.235Z
Learning: The disaster-recovery Lambda functions in CompactConnect get their aws-lambda-powertools dependency from the shared lambda layer rather than individual requirements.txt files, which is why their requirements.txt files can be empty or header-only.

Applied to files:

backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt
backend/compact-connect/lambdas/python/data-events/requirements-dev.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt
backend/compact-connect/requirements.txt
backend/compact-connect/bin/sync_deps.sh
backend/compact-connect/lambdas/python/staff-users/requirements.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements.txt
backend/compact-connect/lambdas/python/custom-resources/requirements.txt
backend/compact-connect/lambdas/python/common/requirements.txt
backend/compact-connect/lambdas/python/data-events/requirements.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt
backend/compact-connect/bin/compile_requirements.sh
backend/compact-connect/README.md
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt
backend/compact-connect/lambdas/python/common/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-07-22T03:36:17.137Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/purchases/requirements-dev.txt:15-0
Timestamp: 2025-07-22T03:36:17.137Z
Learning: In CompactConnect, requirements-dev.txt files for Lambda functions are used exclusively for running tests and development, not for actual Lambda runtime environments. Concerns about runtime compatibility (like OpenSSL versions) don't apply to these development dependency files.

Applied to files:

backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements.txt
backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py
backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt
backend/compact-connect/lambdas/python/data-events/requirements-dev.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt
backend/compact-connect/requirements.txt
backend/compact-connect/bin/sync_deps.sh
backend/compact-connect/lambdas/python/staff-users/requirements.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements.txt
backend/compact-connect/lambdas/python/custom-resources/requirements.txt
backend/compact-connect/lambdas/python/common/requirements.txt
backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py
backend/compact-connect/lambdas/python/data-events/requirements.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt
backend/compact-connect/bin/compile_requirements.sh
backend/compact-connect/README.md
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt
backend/compact-connect/requirements-dev.txt
backend/compact-connect/lambdas/python/common/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-08-12T19:49:24.999Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/lambdas/python/disaster-recovery/requirements.in:1-1
Timestamp: 2025-08-12T19:49:24.999Z
Learning: In CompactConnect disaster-recovery Lambda functions, runtime dependencies like boto3, aws-lambda-powertools, and botocore are provided by lambda layers at deploy time rather than being specified in requirements.in files. The requirements.in file intentionally contains only a comment explaining this approach.

Applied to files:

backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt
backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt
backend/compact-connect/lambdas/python/data-events/requirements-dev.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt
backend/compact-connect/requirements.txt
backend/compact-connect/bin/sync_deps.sh
backend/compact-connect/lambdas/python/custom-resources/requirements.txt
backend/compact-connect/lambdas/python/common/requirements.txt
backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py
backend/compact-connect/lambdas/python/data-events/requirements.txt
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt
backend/compact-connect/bin/compile_requirements.sh
backend/compact-connect/README.md
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt
backend/compact-connect/lambdas/python/common/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-08-22T21:20:35.260Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1029
File: backend/compact-connect/docs/api-specification/latest-oas30.json:468-471
Timestamp: 2025-08-22T21:20:35.260Z
Learning: The file backend/compact-connect/docs/api-specification/latest-oas30.json is auto-generated by API Gateway and should not be modified inline. Any schema changes would need to be addressed at the source in the CDK/CloudFormation definitions.

Applied to files:

backend/compact-connect-ui-app/lambdas/nodejs/cloudfront-csp/README.md
backend/compact-connect/docs/signature_auth_examples.txt
backend/compact-connect/lambdas/nodejs/README.md
backend/compact-connect-ui-app/lambdas/nodejs/README.md
backend/compact-connect/requirements.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-07-21T20:40:56.491Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/common/requirements.txt:7-0
Timestamp: 2025-07-21T20:40:56.491Z
Learning: In CompactConnect, there is only one lambda layer in use for Python lambdas, and this single layer manages the versions of aws-lambda-powertools, boto3, and botocore dependencies. This eliminates concerns about version skew across multiple lambda layers since all Python lambdas share the same dependency management through this single layer.

Applied to files:

backend/compact-connect/lambdas/python/cognito-backup/requirements.txt
backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt
backend/compact-connect/stacks/api_lambda_stack/provider_users.py
backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt
backend/compact-connect/requirements.txt
backend/compact-connect/lambdas/python/common/requirements.txt
backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py
backend/compact-connect/lambdas/python/compact-configuration/requirements.txt
backend/compact-connect/README.md
backend/compact-connect/tests/app/test_pipeline.py
backend/compact-connect/tests/common_constructs/test_queued_lambda_processor.py
backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt
backend/compact-connect/lambdas/python/common/requirements-dev.txt
backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt
backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt

📚 Learning: 2025-08-22T22:02:41.865Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1029
File: backend/compact-connect/lambdas/python/provider-data-v1/tests/function/test_handlers/test_licenses.py:40-73
Timestamp: 2025-08-22T22:02:41.865Z
Learning: The TstLambdas base class in backend/compact-connect/lambdas/python/*/tests/function/__init__.py uses self.addCleanup(self.delete_resources) to automatically clean up test resources (including SQS queues) after each test, preventing cross-test interference. No additional tearDown logic is needed for queue cleanup.

Applied to files:

backend/compact-connect/tests/common_constructs/test_queue_event_listener.py
backend/compact-connect/tests/common_constructs/test_queued_lambda_processor.py

📚 Learning: 2025-08-21T02:51:28.199Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1014
File: backend/compact-connect/lambdas/python/common/requirements.in:4-4
Timestamp: 2025-08-21T02:51:28.199Z
Learning: In CompactConnect, the purchases lambda contains requests as a transitive dependency from the Authorize.net SDK, which is automatically resolved by pip-compile. This should not be manually removed even when requests is also available in the common layer, as it's managed automatically by the dependency resolver.

Applied to files:

backend/compact-connect/lambdas/python/purchases/requirements.txt
backend/compact-connect/bin/sync_deps.sh
backend/compact-connect/bin/compile_requirements.sh
backend/compact-connect/README.md
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-07-21T20:53:14.686Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/multi-account/backups/stacks/backup_account_stack.py:241-263
Timestamp: 2025-07-21T20:53:14.686Z
Learning: In CompactConnect, landonshumway-ia explained that the SSN backup vault DENY policy using 'ForAnyValue:ArnNotEquals' with 'backup:CopyTargets' correctly prevents the vault from being used as a source for copying to other vaults. The policy implements a "data check-in but no check-out" security model where sensitive SSN backups can be copied into the vault but not copied out to external destinations under normal circumstances.

Applied to files:

backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json
backend/compact-connect/stacks/persistent_stack/ssn_table.py

📚 Learning: 2025-09-12T19:53:43.731Z

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1080
File: backend/compact-connect/resources/bootstrap-stack-beta.yaml:582-639
Timestamp: 2025-09-12T19:53:43.731Z
Learning: CompactConnect's CloudFormationExecutionBoundaryPolicy uses a sophisticated defense-in-depth security model: it allows iam:* for infrastructure deployment but constrains this with explicit denies for dangerous actions (account/billing/support changes), prevents self-tampering and boundary policy modification, restricts service access to only CompactConnect services, and includes self-protection mechanisms to prevent privilege escalation.

Applied to files:

backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json
backend/compact-connect/stacks/persistent_stack/ssn_table.py

📚 Learning: 2025-10-15T21:52:47.392Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1135
File: backend/compact-connect/stacks/api_lambda_stack/provider_management.py:100-0
Timestamp: 2025-10-15T21:52:47.392Z
Learning: In the CompactConnect repository, the team prefers to keep cdk-nag suppressions explicit with hard-coded logical IDs (e.g., 'Resource::<ProviderTableEC5D0597.Arn>/index/*') rather than using generic suppressions. This intentional brittleness ensures that when underlying resources change, the suppressions break and force manual review of the IAM policies.

Applied to files:

backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json
backend/compact-connect/common_constructs/user_pool.py
backend/compact-connect/stacks/persistent_stack/ssn_table.py

📚 Learning: 2025-08-12T19:18:06.657Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/stacks/disaster_recovery_stack/restore_dynamo_db_table_step_function.py:74-99
Timestamp: 2025-08-12T19:18:06.657Z
Learning: For DynamoDB RestoreTableToPointInTime operations in AWS Step Functions, the IAM policy must include CRUD permissions (BatchWriteItem, DeleteItem, GetItem, PutItem, Query, Scan, UpdateItem) in addition to CreateBackup, DescribeBackup, RestoreTableToPointInTime, and DescribeTable actions, as these are required by AWS for the point-in-time recovery process to populate the restored table.

Applied to files:

backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json
backend/compact-connect/stacks/persistent_stack/ssn_table.py

📚 Learning: 2025-06-06T02:02:02.538Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 824
File: backend/compact-connect/lambdas/python/data-events/tests/function/test_encumbrance_events.py:79-79
Timestamp: 2025-06-06T02:02:02.538Z
Learning: The CompactConnect project uses Ruff for formatting and linting, not Pylint. Suggestions for Pylint-specific disable comments are not applicable to this codebase.

Applied to files:

backend/compact-connect/bin/compile_requirements.sh

📚 Learning: 2025-10-10T18:45:43.801Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1114
File: backend/compact-connect-ui-app/stacks/frontend_deployment_stack/deployment.py:34-35
Timestamp: 2025-10-10T18:45:43.801Z
Learning: In backend/compact-connect-ui-app/stacks/frontend_deployment_stack/deployment.py, the cdk.context.deploy-example.json file is intentionally minimal and serves as a template, not for actual deployments. Actual deployment environments (test, beta, prod, sandbox) contain all required environment-specific keys like statsig_key, app_env, recaptcha_public_key, and robots_meta. This is by design.

Applied to files:

backend/compact-connect/README.md

📚 Learning: 2025-08-25T22:39:05.553Z

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1005
File: backend/compact-connect/tests/smoke/hmac_auth_smoke_tests.py:19-25
Timestamp: 2025-08-25T22:39:05.553Z
Learning: In the CompactConnect project, CLI scripts are written with the convention of assuming a specific current working directory (CWD), so CWD-relative paths in sys.path adjustments are intentional and acceptable within this codebase's standards.

Applied to files:

backend/compact-connect/README.md

📚 Learning: 2025-06-04T17:38:22.392Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 824
File: backend/compact-connect/tests/smoke/encumbrance_smoke_tests.py:461-640
Timestamp: 2025-06-04T17:38:22.392Z
Learning: For smoke tests in backend/compact-connect/tests/smoke/, prioritize linear narrative readability over reducing complexity metrics. These tests are designed to be run manually by developers for verification, and should be readable from top to bottom like a story, allowing developers to follow the complete workflow without jumping between helper methods.

Applied to files:

backend/compact-connect/tests/app/base.py

📚 Learning: 2025-06-23T20:19:18.952Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 877
File: backend/compact-connect/tests/smoke/practitioner_email_update_smoke_tests.py:22-192
Timestamp: 2025-06-23T20:19:18.952Z
Learning: In the CompactConnect project, smoke test functions (like test_practitioner_email_update in backend/compact-connect/tests/smoke/practitioner_email_update_smoke_tests.py) should remain as single large functions rather than being broken down into smaller helper functions, based on the project maintainer's preference and reasoning.

Applied to files:

backend/compact-connect/lambdas/python/common/tests/function/test_data_model/test_transaction_client.py

📚 Learning: 2025-08-12T19:18:06.657Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/stacks/disaster_recovery_stack/restore_dynamo_db_table_step_function.py:74-99
Timestamp: 2025-08-12T19:18:06.657Z
Learning: AWS DynamoDB RestoreTableToPointInTime operation requires CRUD permissions (BatchWriteItem, DeleteItem, GetItem, PutItem, Query, Scan, UpdateItem) on the target table because the restore process itself uses these actions to populate the restored table from the point-in-time backup. These aren't permissions for subsequent operations but are integral to the restore process itself, as documented in the AWS service authorization reference.

Applied to files:

backend/compact-connect/stacks/persistent_stack/ssn_table.py

🧬 Code graph analysis (1)

backend/compact-connect/stacks/persistent_stack/ssn_table.py (1)

backend/compact-connect/lambdas/python/common/cc_common/config.py (1)

ssn_index_name (179-180)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

GitHub Check: TestApp
GitHub Check: TestApp

🔇 Additional comments (63)

backend/compact-connect/app_clients/.gitignore (1)

1-2: Add key file patterns to .gitignore for security.

These patterns correctly exclude private and public key files from version control, preventing accidental commits of sensitive cryptographic material.

backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt (1)

2-2: Python 3.14 pip-compile header update looks good.

The header comment reflects the correct Python 3.14 version used during pip-compile generation, aligning with the runtime upgrade objectives. This file structure (header-only, no dependencies) is consistent with the established pattern in CompactConnect where disaster-recovery Lambda functions source their dependencies from the shared lambda layer rather than individual requirements.txt files. Based on learnings.

backend/compact-connect/lambdas/python/compact-configuration/requirements-dev.txt (2)

2-2: Header correctly reflects Python 3.14 upgrade.

The autogenerated header has been properly updated to indicate Python 3.14 as intended by this PR's runtime upgrade objectives.

7-39: Development dependency updates are appropriate.

All pinned versions have been updated as expected from pip-compile's dependency resolution. Since requirements-dev.txt is used exclusively for development and testing, these updates pose no runtime concerns. The version bumps (boto3/botocore 1.40.56→1.41.0, certifi 2025.10.5→2025.11.12, moto 5.1.15→5.1.17, py-partiql-parser 0.6.1→0.6.3) are minor/patch releases appropriate for maintenance upgrades.

Based on learnings: Development dependencies are isolated from Lambda runtime environments; boto3, botocore, and aws-lambda-powertools are provided by the shared lambda layer at deploy time.

backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt (1)

2-2: Header update aligns with Python 3.14 runtime upgrade.

The pip-compile header correctly reflects the Python 3.14 upgrade for this lambda. Per the project's pattern, the pip-compile version is separate from the CI/CD installation environment, so this is compatible with the project's dependency management approach. Based on learnings

backend/compact-connect/lambdas/python/data-events/requirements-dev.txt (2)

2-2: Header correctly updated to Python 3.14.

The autogenerated header comment now reflects Python 3.14, aligning with the PR objectives to upgrade Python runtimes.

7-38: Dependency updates appear safe and routine.

All version updates are patch or minor bumps (boto3/botocore 1.40.56→1.41.0, certifi 2025.10.5→2025.11.12, moto 5.1.15→5.1.17, py-partiql-parser 0.6.1→0.6.3) with no major version changes or apparent breaking updates. Since this file is autogenerated by pip-compile for development/testing only (not runtime dependencies), standard update compatibility is expected.

To confirm there are no compatibility issues between Python 3.14 and the key testing dependencies (boto3 1.41.0, moto 5.1.17), you may want to verify that your test suite passes against this updated file.

backend/compact-connect/requirements.txt (1)

61-70: Typeguard major version bump (v2 → v4) requires verification.

The update from typeguard 2.13.3 → 4.2.1 is a major version jump across multiple major versions. While this aligns with Python 3.14 support objectives and the PR indicates testing was performed, confirm that no runtime behavior changes or API incompatibilities exist with this version in the CDK tooling.

Per your learnings, the Python version in the file header is separate from the actual Lambda runtime environment, so this version change affects only the CDK build/compilation environment.

Can you confirm the typeguard v4 compatibility was validated during testing, particularly with aws-cdk packages and jsii which depend on it (lines 63–70)?

backend/compact-connect/lambdas/python/provider-data-v1/requirements-dev.txt (2)

2-2: Python 3.14 header correctly updated.

The pip-compile header now reflects Python 3.14 as intended per the PR objectives. This is consistent with the broader runtime upgrade effort.

7-14: Verify compatibility of major faker version bump.

Most dependency updates are routine patch/minor increments, but faker jumped from 28.4.1 to 37.12.0—a major version upgrade. Since this is a dev-only file (per learnings, requirements-dev.txt is used exclusively for testing), this is lower risk for runtime environments, but you should verify that the test suite still passes with this newer faker version and that no test code depends on faker 28.x-specific behavior.

The tzdata addition (2025.2 with "via faker" comment) is appropriate as an expected transitive dependency of the newer faker version.

Have you confirmed that the test suite runs successfully with faker 37.12.0?

Also applies to: 24-24, 38-38, 40-40, 63-64

backend/compact-connect/stacks/persistent_stack/ssn_table.py (1)

175-177: Correct fix for circular reference issue.

Using the SSN_TABLE_NAME constant instead of self.table_name properly avoids the circular reference that would occur when constructing the resource policy during table initialization. The constant maintains consistency with the table name parameter on line 86.

backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json (1)

37-47: Test snapshot correctly reflects the resource policy.

The new Deny statement accurately captures the policy added in ssn_table.py (lines 157-181). The NotResource scoping correctly restricts GetItem, Query, and ConditionCheckItem operations to only the ssnIndex GSI, preventing SSN exposure in CloudTrail logs.

backend/compact-connect/lambdas/python/cognito-backup/requirements-dev.txt (4)

2-2: Development dependencies align with PR upgrade objectives.

The dependency updates reflect the standard maintenance cycle and are consistent with the PR objective to upgrade Python to 3.14. All changes are patch/minor version bumps with no apparent breaking changes to the development toolchain.

Also applies to: 7-7, 9-9, 13-13, 19-19, 40-40, 46-46, 52-52, 58-58

1-6: Based on the verification results gathered, I can now provide the final assessment:

File was properly regenerated with pip-compile using Python 3.14.

The header and pip-compile command confirm correct regeneration. This is a development-only dependencies file (per CompactConnect practices), so runtime compatibility concerns do not apply. The pytest 9.0.1 upgrade is a major version bump with breaking changes around collection behavior, CI detection, and argument handling, but these are unlikely to impact standard Cognito backup test patterns. The dependencies resolve appropriately from the specified constraints in requirements-dev.in.

7-87: All pinned package versions verified—no known CVEs detected.

No public security advisories were found for aws-lambda-powertools 3.23.0, boto3 1.41.0, botocore 1.41.0, moto 5.1.17, or pytest 9.0.1 in major vulnerability databases as of November 20, 2025. The versions are current and available for installation.

58-58: Verify pytest 9.0.1 compatibility with existing test suite.

The upgrade from pytest 8.4.2 to 9.0.1 introduces confirmed breaking changes, including PytestRemovedIn9Warning deprecations now causing test failures, changes to CLI/path handling, and dropped Python 3.9 support. The test file backend/compact-connect/lambdas/python/cognito-backup/tests/function/test_cognito_backup.py must be verified to pass with the new version. No custom pytest plugins or fixtures were detected, which reduces risk, but manual testing is required before merging.

backend/compact-connect/lambdas/python/disaster-recovery/requirements-dev.txt (2)

1-6: Header reflects expected Python 3.14 runtime upgrade.

The file header correctly reflects the Python 3.14 version as part of the runtime upgrade objective. Since this is an autogenerated pip-compile output, the regeneration is expected and appropriate.

2-2: Python 3.14 compatibility verified for development dependencies.

boto3 1.41.0 and botocore 1.41.0 both officially support Python 3.14. moto 5.1.17 has no upper Python bound and was selected by pip-compile. All version updates are minor-version bumps with no breaking changes detected. This autogenerated requirements file is properly updated and ready.

backend/compact-connect/common_constructs/user_pool.py (1)

223-226: Suppression is appropriate—no changes needed.

The AwsSolutions-L1 suppression follows the established pattern in this file for the auto-generated CDK custom resource Lambda (AWS679f53fac002430cb0da5b7982bd2287). Since the construct ID is auto-generated by CDK, dynamic path-based suppressions are required here rather than hard-coded IDs. The same Lambda already has three other suppressions using this identical approach (AwsSolutions-IAM4, HIPAA.Security-LambdaDLQ, and HIPAA.Security-LambdaInsideVPC at lines 210–235), so the AwsSolutions-L1 addition is consistent. Your reason "We do not maintain this lambda runtime. It will be updated with future CDK versions" is accurate—this is an AWS-managed resource outside your control, and CDK upgrades will handle runtime updates.

backend/compact-connect/lambdas/python/staff-users/requirements-dev.txt (3)

2-5: Python 3.14 update is consistent with PR objectives.

The header correctly reflects the Python 3.14 bump for pip-compile, aligning with the PR's runtime upgrade initiative.

7-7: boto3/botocore versions in requirements-dev.txt align with shared lambda layer—no version skew detected.

Verification confirms:

boto3==1.41.0 ✅ matches shared layer

botocore==1.41.0 ✅ matches shared layer

moto==5.1.17 is dev/test-only (not in shared layer, as expected per project pattern)

No changes needed.

26-26: Code is compatible with Faker 37.12.0—no breaking changes found.

Faker v37.x releases show only incremental provider additions and bugfixes, and the .unique accessor with methods like .email(), .last_name(), and .first_name() are stable and have no documented breaking changes in recent releases. The test code in tests/function/__init__.py uses standard Faker patterns (locale initialization and .unique methods) that remain compatible with this version.

backend/compact-connect/lambdas/python/compact-configuration/requirements.txt (1)

2-2: LGTM! Autogenerated header updated for Python 3.14.

The pip-compile version update aligns with the broader runtime upgrade across the project.

Based on learnings.

backend/compact-connect/lambdas/python/staff-users/requirements.txt (1)

2-2: LGTM! Autogenerated header updated for Python 3.14.

Consistent with the project-wide Python runtime upgrade.

Based on learnings.

backend/compact-connect/lambdas/python/staff-user-pre-token/requirements.txt (1)

2-2: LGTM! Autogenerated header updated for Python 3.14.

Consistent with the project-wide Python runtime upgrade.

Based on learnings.

backend/compact-connect/stacks/persistent_stack/__init__.py (1)

67-67: LGTM! Compatible runtimes correctly updated.

The layer now supports both Python 3.12 (for the purchases lambda) and Python 3.14 (for upgraded lambdas), which aligns perfectly with the PR objectives.

backend/compact-connect/lambdas/python/custom-resources/requirements.txt (1)

2-2: LGTM! Autogenerated header updated for Python 3.14.

Consistent with the project-wide Python runtime upgrade.

Based on learnings.

backend/compact-connect/common_constructs/nodejs_function.py (1)

78-78: Verify regional availability before defaulting to Node.js 24.x.

AWS announced Node.js 24 as a planned Lambda runtime for November 2025, but availability may not yet be uniform across all regions and consoles. Current AWS documentation lists only Node.js 20 and 22 as supported runtimes.

Setting Node.js 24.x as the default runtime for all NodejsFunction constructs creates a risk of deployment failures in regions where it's not yet available. Confirm:

Regional availability in your target deployment regions

Whether this should be a soft default (allowing override) rather than hard default

Dependency compatibility with Node.js 24.x

backend/compact-connect/lambdas/python/common/cc_common/data_model/transaction_client.py (1)

378-381: Trailing comma in logger.error call is harmless and keeps behavior intact

The call signature and kwarg name still match the test expectations and existing logging patterns; this is a pure formatting tweak with no functional impact.

backend/compact-connect/lambdas/nodejs/README.md (1)

6-9: Node 24.X prerequisite aligns with the runtime upgrade

Updating the documented prerequisite to Node 24.X matches the broader runtime changes and keeps dev setup instructions in sync with deployed Lambdas and CI.

If you haven’t already, double‑check that local tooling and any non‑GitHub CI jobs are also using Node 24.x so this prerequisite accurately reflects all environments.

backend/compact-connect/lambdas/python/data-events/requirements.txt (1)

1-5: pip-compile header updated to Python 3.14 and looks consistent

The autogenerated comment now reflecting Python 3.14 matches the project’s runtime upgrade direction and doesn’t affect dependency resolution behavior by itself.

On the next dependency refresh, ensure pip-compile is actually run under Python 3.14 so this header remains an accurate description of how the file was generated.

backend/compact-connect-ui-app/lambdas/nodejs/cloudfront-csp/README.md (1)

10-13: CSP Lambda README now correctly documents Node 24.X

The prerequisite bump to Node 24.X matches the runtime upgrades elsewhere and keeps local setup instructions aligned with the deployed Edge Lambda environment.

Confirm that the CloudFront CSP Lambda’s CDK runtime and any local test harnesses are also on Node 24.x so this README stays authoritative for contributors.

backend/compact-connect/lambdas/python/common/tests/function/test_data_model/test_transaction_client.py (1)

263-265: Test signature reformat is non-functional and fine

The patched logger target and parameter list are unchanged; this is only a layout tweak and keeps the test behavior and expectations identical.

backend/compact-connect-ui-app/lambdas/nodejs/README.md (1)

7-7: LGTM!

Documentation correctly updated to reflect the Node.js 24.X runtime requirement, consistent with the workflow changes.

backend/compact-connect/tests/app/base.py (1)

231-233: LGTM - Improved test organization.

Moving these inspection calls inside the subTest context improves test isolation and reporting. Each inspection will now be properly scoped under the persistent_stack subTest.

backend/compact-connect/lambdas/python/staff-user-pre-token/requirements-dev.txt (2)

14-14: No issues found — certifi version 2025.11.12 is a valid official release.

The version was officially released to PyPI on November 12, 2025, and is available on multiple package repositories. No action required.

2-2: Test moto 5.1.17 and py-partiql-parser 0.6.3 with Python 3.14 before merging.

py-partiql-parser 0.6.3 is a pure Python universal wheel compatible with Python 3, so it should work with Python 3.14. However, moto 5.1.17 has no explicit Python 3.14 support documented despite requiring Python >=3.9. Run your test suite on Python 3.14 to verify moto compatibility, as the broader >=3.9 requirement does not guarantee support for newer Python versions.

.github/workflows/check-compact-connect-ui-app.yml (1)

51-51: Node.js 24.11.1 is confirmed as a valid, stable LTS release.

Node.js v24.11.1 is an official stable (LTS) patch release published on Nov 11, 2025, making it suitable for production use. The version update from 22.1.0 to 24.11.1 is justified.

.github/workflows/check-compact-connect.yml (1)

51-51: Node.js 24.11.1 is a valid and stable official release.

Node.js v24.11.1 is an official release as part of the v24 "Krypton" LTS/stable line. The version specification in the workflow file is correct and appropriate.

backend/compact-connect/lambdas/python/common/requirements.txt (2)

19-19: certifi version 2025.11.12 is a valid official release.

certifi 2025.11.12 is an official release uploaded to PyPI on Nov 12, 2025, with corresponding GitHub tag and downstream package listings. The version uses certifi's standard date-based versioning format (YYYY.MM.DD) and is current as of the release date.

2-2: Python 3.14 and AWS SDK compatibility confirmed.

The web search verification confirms that aws-lambda-powertools 3.23.0, boto3 1.41.0, and botocore 1.41.0 are all fully compatible with Python 3.14. All three packages publish py3 wheels with no python_requires restrictions excluding Python 3.14, and AWS documentation confirms Powertools support for the runtime. Since CompactConnect uses a single lambda layer to manage these dependencies across all Python lambdas, the update is safe and consistently applied.

backend/compact-connect/lambdas/python/custom-resources/requirements-dev.txt (2)

2-2: Python 3.14 compatibility verified for both dependencies.

moto 5.1.17 requires Python >=3.9 and publishes py3 wheels, so it is compatible with Python 3.14. py-partiql-parser 0.6.3 is a pure-Python package distributed as a universal py3 wheel, compatible with Python 3.14.

14-14: certifi version 2025.11.12 is valid.

The version is an official PyPI release uploaded on November 12, 2025, with provenance and signature metadata. The date-based versioning scheme (YYYY.MM.DD) is standard for this package.

backend/compact-connect/lambdas/python/cognito-backup/requirements.txt (1)

2-2: The review comment is based on a misunderstanding of the CompactConnect architecture.

The Python 3.14 version shown in the pip-compile header comment reflects the version used for dependency resolution, not the Lambda runtime environment. According to the project's CI/CD configuration, dependencies are installed by a Python 3.12 container, which is the actual Lambda runtime environment. The compatibility concern should focus on Python 3.12, not Python 3.14.

Likely an incorrect or invalid review comment.

backend/compact-connect/bin/compile_requirements.sh (1)

19-23: LGTM - Clear documentation of purchases lambda isolation.

The commented-out pip-compile commands and explanatory note clearly document why the purchases lambda must be managed separately due to the Authorize.Net SDK's Python version constraint.

backend/compact-connect/bin/sync_deps.sh (1)

27-30: LGTM - Consistent with compile_requirements.sh approach.

The exclusion of purchases lambda requirements from pip-sync is properly documented and consistent with the separate environment management approach.

backend/compact-connect/README.md (2)

26-36: LGTM - Comprehensive documentation of Python version requirements.

The updated prerequisites clearly document the Python 3.14 requirement and provide detailed context about the purchases lambda exception. The explanation of the Authorize.Net SDK constraint and the need for a separate Python 3.12 environment is very helpful for developers.

81-91: LGTM - Helpful documentation of dependency management workflow.

The new "Convenience scripts" section clearly documents the dependency management workflow and reinforces the separate management approach for the purchases lambda.

backend/compact-connect/lambdas/python/purchases/requirements.txt (1)

9-9: LGTM - Security dependency update.

The certifi update to 2025.11.12 is appropriate and likely includes important security fixes.

backend/compact-connect/lambdas/python/common/common_test/sign_request.py (1)

50-78: LGTM - Good refactoring for reusability.

Extracting get_string_to_sign as a separate function improves code organization and makes the signature string construction logic independently testable and reusable. The refactoring maintains the original behavior while enhancing maintainability.

backend/compact-connect/lambdas/python/purchases/requirements-dev.txt (1)

2-144: LGTM - Appropriate dependency updates for purchases lambda.

The requirements file correctly uses Python 3.12 and includes reasonable dependency updates. The addition of tzdata is appropriately linked to faker's requirements.

Based on learnings

backend/compact-connect/lambdas/python/common/requirements-dev.txt (1)

2-177: LGTM - Dependencies updated for Python 3.14.

The requirements file correctly reflects the Python 3.14 upgrade with appropriate dependency updates. The tzdata addition aligns with faker's requirements.

Based on learnings

backend/compact-connect/common_constructs/python_function.py (1)

32-32: No action required—purchases lambdas explicitly override runtime to Python 3.12.

The purchases lambda functions (PostPurchasePrivilegesHandler and GetPurchasePrivilegeOptionsHandler) in backend/compact-connect/stacks/api_lambda_stack/purchases.py both explicitly set runtime=Runtime.PYTHON_3_12, ensuring they remain on Python 3.12 despite the updated default in PythonFunction.

backend/compact-connect/stacks/api_lambda_stack/provider_users.py (1)

559-559: LGTM!

The runtime upgrade for the dummy function is correct and maintains consistency with the project-wide Python 3.14 migration.

backend/compact-connect/tests/app/test_pipeline.py (1)

286-286: LGTM!

The test correctly reflects the dual-runtime strategy where Python 3.12 is retained for the purchases lambda while other lambdas are upgraded to Python 3.14, as stated in the PR objectives.

backend/compact-connect/tests/common_constructs/test_cognito_user_backup.py (1)

144-144: LGTM!

The test assertion correctly validates the Python 3.14 runtime and is consistent with the test setup on Line 46.

backend/compact-connect/docs/client_signature_auth.md (1)

143-145: LGTM!

The documentation enhancement adds a valuable reference to concrete signature authentication examples, which will help developers implementing the authentication scheme.

backend/compact-connect/docs/signature_auth_examples.txt (1)

1-149: LGTM!

This is a valuable addition to the signature authentication documentation. The examples cover diverse scenarios (different HTTP methods, with/without query parameters, various key IDs) and provide both plaintext and base64-encoded formats, which will help developers verify their implementations.

backend/compact-connect/tests/common_constructs/test_data_migration.py (1)

32-32: AWS Lambda Python 3.14 support is confirmed.

AWS Lambda added a managed Python 3.14 runtime (python3.14) for functions and container base images on November 18, 2025. The code change is valid and no further action is needed.

backend/compact-connect/requirements-dev.txt (4)

2-2: Python 3.14 header correctly updated.

The header comment now reflects Python 3.14, consistent with the PR objective to upgrade to Python 3.14.

11-11: Conservative patch/minor version updates look appropriate.

The other dependency updates (cachecontrol, certifi, click, coverage, pip-tools, ruff) are patch or minor version bumps, which are generally low-risk and appropriate for maintaining current best practices and security patches.

Also applies to: 15-15, 19-19, 21-21, 59-59, 91-91

97-98: tzdata is an intentional transitive dependency.

Faker 37.12.0 has tzdata as a required dependency, confirming the addition shown in requirements-dev.txt is expected and not an oversight. The pip-tools format correctly annotates this as "# via faker".

29-29: Verify that Python 3.10+ is available and run the full test suite in your environment.

The major version upgrades for faker (28.4.1 → 37.12.0) and pytest (8.4.2 → 9.0.1) appear compatible with the codebase:

faker 37.12.0: Successfully imports; no deprecated .seed() patterns or breaking API usage detected in tests.

pytest 9.0.1: Loads successfully; no deprecated pytest APIs found in test code. However, pytest 9.0.1 requires Python 3.10+ (drops support for Python 3.9).

In the sandbox, both packages installed and loaded without errors, though full verification requires running the complete test suite with all dependencies (e.g., aws_cdk) in your environment. Confirm that your Python runtime meets the 3.10+ requirement, then run your full test suite to validate compatibility.

backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py

backend/compact-connect/pipeline/backend_pipeline.py

### Description List - Addressing the Node CVE in an indirect dependency ### Testing List - Code review - Integrate test with some email events in *test* Closes csg-org#1205

### Requirements List - _None_ ### Description List - Added Investigation model - Updated License & Licensee models with related investigation props & methods - Also updated encumber modal with minor layout update from latest designs - Updated network & store layers for API calls to add / update investigations - Updated LicenseeDetail page with banner to indicate a current investigation - Updated the LicenseCard & PrivilegeCard components to support adding & ending investigations - This includes chaining the encumber workflow if selected by the user ### Testing List - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Code review - Testing - Login as a staff with state admin permissions - Locate a licensee with licenses / privileges in your admin state - Use the 3-dot menu of the license / privilege to Add investigation - Workflow should match the figma designs - The card Discipline status should now be Investigation - There should be a banner at the top denoting the user is under investigation, matching the figma designs - Use the 3-dot menu of the license / privilege to End investigation - First, choose the no encumbrance option - Ensure the workflow completes and the licensee is no longer shown as under investigation - Use the 3-dot menu to Add investigation - Use the 3-dot menu to End investigation - This time, choose the encumber option and complete the encumber workflow - Ensure the workflow completes and the licensee is no longer shown as under investigation, but the license / privilege is now shown as encumbered - Additionally play with different scenarios for: - Starting an investigation - Ending an investigation with an encumbrance - Ending an investigation without an encumbrance Closes csg-org#1132  ## Summary by CodeRabbit * **New Features** * Investigation workflows for licenses and privileges: start/end actions, multi-step modals, per‑investigation selection, encumbrance options, and visible "under investigation" status with a licensee alert. * **Style** * Responsive two‑column/static layout for detail blocks, wider action menus, section dividers, and new yellow alert color palette. * **Accessibility** * Improved modal keyboard focus handling and ARIA live region messaging. * **Localization** * Added English and Spanish translations for investigation flows and alerts. * **Tests** * New unit tests for Investigation model, license/licensee logic, and store actions. * **Chores** * API/mocks and sample data updated to support investigation create/update and WY mock data.  --------- Co-authored-by: Justin Frahm <justin@inspiringapps.com>

coderabbitai

Actionable comments posted: 2

Caution

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

⚠️ Outside diff range comments (3)

webroot/src/components/PrivilegeCard/PrivilegeCard.less (1)
76-128: Anchor .new-section::before to the menu item

.privilege-menu-item.new-section::before is position: absolute, but .privilege-menu-item itself is not positioned, so the pseudo-element will be laid out relative to .privilege-menu instead of the individual item. That can place the divider at the top of the menu rather than just above the new section.

Consider anchoring it to the item:
 .privilege-menu {
   ...
   .privilege-menu-item {
+    position: relative; // or add this only to &.new-section
     ...
     &.new-section {
       margin-top: 0.4rem;
       padding-top: 1rem;
webroot/src/components/LicenseCard/LicenseCard.less (1)
121-175: Fix separator positioning for .license-menu-item.new-section

&.new-section::before is position: absolute, but .license-menu-item isn’t positioned, so the separator’s containing block becomes .license-menu. That will anchor the line to the top of the whole menu rather than the start of the new section item.

Consider making the new-section item positioned so the separator aligns with that item:
 .license-menu-item {
     padding: 0.6rem 0.8rem;
     border-radius: 8px;
     color: @fontColor;
     font-weight: @fontWeightBold;
     cursor: pointer;
@@
-    &.new-section {
+    &.new-section {
+        position: relative;
         margin-top: 0.4rem;
         padding-top: 1rem;
webroot/src/components/LicenseCard/LicenseCard.ts (1)
462-478: Stale selectedInvestigation after cancelling encumber may cause incorrect end‑investigation behavior

The new submitEncumberLicense branching correctly calls updateInvestigationLicenseRequest when selectedInvestigation is set and falls back to encumberLicenseRequest otherwise. It also clears selectedInvestigation on success, which is good.

However, if the user comes from “End Investigation with encumbrance”, then cancels out of the encumber modal (calling closeEncumberLicenseModal), selectedInvestigation is not cleared. Later, reopening the end‑investigation modal could show no checkbox selected while selectedInvestigation is still set, allowing a submit against an unintended investigation.

To align with PrivilegeCard and avoid stale state, clear selectedInvestigation whenever the encumber modal is closed:
    closeEncumberLicenseModal(event?: Event): void {
        event?.preventDefault();
        this.isEncumberLicenseModalDisplayed = false;
        this.isEncumberLicenseModalSuccess = false;
+       this.selectedInvestigation = null;
    }
Also applies to: 500-568

🧹 Nitpick comments (19)

webroot/src/styles.common/_colors.less (1)

63-68: Yellow color palette follows established patterns with a minor deviation worth noting.

The new yellow palette integrates well with the existing color system. However, the lighten percentage (15%) differs from the standard pattern used in other color families (typically 40%). While this may be intentional to maintain yellow visibility and readability, verify that this is the desired visual behavior.

backend/compact-connect/tests/app/base.py (1)

252-361: Approve with note on test flexibility.

The refactoring from static policy snapshots to dynamic has_resource assertions successfully accommodates the CDK upgrade. The approach is sound:

Dynamic principal ARN array construction correctly handles the 5 core roles

Conditional backup role handling appropriately uses Match.any_value() for nested stack outputs

KMS key policy validation properly verifies the deny-except-principals pattern

Note: The use of Match.any_value() (lines 265, 333) trades test strictness for maintainability. While this makes tests more flexible for CDK upgrades, it means the exact principal lists aren't validated. Given that the PR description confirms testing of SSN functionality and backups, this is an acceptable trade-off for this upgrade.

If desired, you could strengthen validation by constructing a similar explicit array for the DynamoDB resource policy principals (line 333) instead of using Match.any_value(), similar to the KMS key policy approach.
webroot/src/components/PrivilegeCard/PrivilegeCard.less (1)
303-337: Optional: tighten ellipsis behavior on .static-value

.static-value uses overflow: hidden and text-overflow: ellipsis, but without white-space: nowrap long content may wrap instead of truncating with an ellipsis.

If you want single-line truncation, consider:
 .static-input {
   ...
   .static-value {
-    overflow: hidden;
-    font-size: @fontSize;
-    text-overflow: ellipsis;
+    overflow: hidden;
+    font-size: @fontSize;
+    white-space: nowrap;
+    text-overflow: ellipsis;
   }
 }
webroot/src/models/Licensee/Licensee.model.spec.ts (1)
1131-1174: Under‑investigation aggregation test is solid; minor assertion tweak optional

The new test constructing active investigations on both a license and a privilege, then asserting:

hasUnderInvestigationLicenses/Privileges and isUnderInvestigation are true,

underInvestigationStates() returns two distinct states (AL, CO),

canPurchasePrivileges() remains true,

accurately exercises the intended behavior that investigations are surfaced but do not block purchases.

If you want to make the state assertions slightly less brittle, you could match by abbrev instead of constructing new State instances, e.g.:
expect(licensee.underInvestigationStates()).to.matchPattern([
  { abbrev: 'al', '...': '' },
  { abbrev: 'co', '...': '' },
]);
webroot/src/models/Investigation/Investigation.model.spec.ts (1)

20-166: Strong Investigation model coverage; minor note on time‑dependent tests

The spec does a good job exercising defaults, arbitrary values (including invalid dates), edge cases for isActive (start only, end only, start/end same day), and the serializer mapping (including State name resolution and formatted date displays). This matches the intended defensive behavior around investigations, including treating “endDate today” as lifted and allowing endDate‑only investigations to count as active. Based on learnings

If you ever see flakiness around isActive tests, consider optionally stubbing moment() or injecting “now” so tests don’t depend on wall‑clock time, but this isn’t blocking.

webroot/src/pages/LicensingDetail/LicensingDetail.ts (1)

111-128: Investigation alert content behavior when states are missing

The computed logic looks good and safely handles a missing licensee. One small edge case: if isUnderInvestigation() ever returns true while underInvestigationStates() is empty (e.g., partial data), isLicenseeUnderInvestigation will be true but licenseeInvestigationAlertContent will be ''. If that’s possible, you might want a generic fallback like licensing.underInvestigationAlertStatus so the banner never renders empty content.

webroot/src/components/LicenseCard/LicenseCard.vue (1)

134-153: Investigation modal flows are consistent and safely gated

The refactored static detail blocks in the encumber modal and the new add/end investigation modals reuse the existing modal/layout conventions (static containers, live regions, focus-trap handlers). In the end-investigation flow, the continue action is disabled until selectedInvestigation is truthy, preventing the confirm step from rendering without a selection, and the selection rows correctly become inactive once investigation.hasEndDate() is true, mirroring the unencumber behavior. Overall these flows look solid.

If you later find isFormValid isn’t meaningful for the selection-only steps, you could simplify those buttons to depend solely on !isFormLoading && selectedInvestigation.

Also applies to: 352-589

webroot/src/components/PrivilegeCard/PrivilegeCard.vue (1)

412-649: Privilege investigation modals mirror license flows; consider param naming consistency

The new privilege add/end investigation modals closely mirror the license modals and reuse existing patterns: focus trapping, live regions, selection rows that become inactive when investigation.hasEndDate() is true, and button enablement gated by selectedInvestigation so you can’t proceed without a choice. That’s all consistent with prior adverse action behavior.

One minor readability point: in related store/action tests, the privilege investigation flows use a licenseState parameter name rather than privilegeState, which differs from the encumber/delete privilege flows. If the underlying action signatures also use licenseState, that’s functionally fine, but you may want to standardize on privilegeState for privilege-specific flows to avoid confusion.

webroot/src/store/users/users.spec.ts (1)

1060-1153: Privilege investigation action tests are solid; watch naming consistency with privilege state

The privilege investigation action specs (createInvestigationPrivilege*, updateInvestigationPrivilege*) provide analogous coverage to the license actions, including the intentional error cases and failure dispatch assertions, which is great for catching regression in the new flows.

One small nit: these tests construct the payload using a licenseState property, whereas other privilege flows in this file (e.g., encumber/delete privilege) use privilegeState. If the corresponding actions also use licenseState, behavior is correct but the naming inconsistency could be confusing next time someone extends these flows. Standardizing on privilegeState for privilege-specific actions would improve clarity.

webroot/src/components/LicenseCard/LicenseCard.less (1)

261-403: Investigation/unencumber modal layout changes are consistent and readable

The new .static-container, .unencumber-row / .end-investigation-row groupings, dual .unencumber-select / .end-investigation-select handling, and .static-input / .info-block patterns follow the existing responsive and spacing conventions in this file. The extension of .encumbrance-dates to .investigation-dates keeps the typography consistent for both flows.

webroot/src/network/data.api.ts (1)

215-256: Thin investigation wrappers correctly delegate to licenseDataApi

The four new methods mirror the existing pattern in this class: they forward all arguments through to the corresponding LicenseDataApi calls without altering behavior, which keeps the surface area consistent for callers.

Minor nit only: in the JSDoc for updateLicenseInvestigation, the phrase “add to the privilege” is misleading in the license context; consider updating that to “add to the license” for clarity.

Also applies to: 326-374

webroot/src/network/licenseApi/data.api.ts (2)

319-388: License investigation create/update endpoints align with existing encumbrance patterns

The new createLicenseInvestigation and updateLicenseInvestigation methods:

Hit the expected /licenses/.../investigation paths with POST/PATCH.

Always send action: 'close' on update, with an optional encumbrance block that reuses the same feature-gated NPDB category structure and encumbranceEffectiveDate naming as encumberLicense.

This keeps investigation closure + optional encumbrance behavior consistent with your current encumbrance APIs. No issues spotted.

477-546: Privilege investigation endpoints mirror the license APIs correctly

createPrivilegeInvestigation and updatePrivilegeInvestigation use the privilege-specific paths and mirror the license versions’ behavior:

POST to /privileges/.../investigation with an empty body.

PATCH with action: 'close' and an optional, feature-gated encumbrance payload shaped exactly like encumberPrivilege.

The symmetry between license and privilege implementations should make future maintenance straightforward.

webroot/src/store/users/users.actions.ts (2)

195-254: License investigation actions follow established Vuex patterns

The create/update license investigation actions correctly:

Commit the corresponding REQUEST mutations.

Call dataApi.createLicenseInvestigation / updateLicenseInvestigation with the expected arguments.

Dispatch SUCCESS/FAILURE and rethrow errors, matching the encumber license flows.

If you find these patterns proliferating further, you could consider a small helper to DRY the “commit → api call → success/failure dispatch” sequence, but it’s not required for clarity here.

353-412: Privilege investigation actions are wired consistently with license actions

The privilege investigation request/success/failure actions mirror the license counterparts and existing privilege encumber/unencumber actions, so store behavior remains predictable and testable.
webroot/src/components/PrivilegeCard/PrivilegeCard.ts (2)
278-289: Consider resetting investigationInputs when initializing end‑investigation form

The add/end investigation initializers follow existing patterns and look correct; endInvestigation inputs are disabled when an investigation already has an end date, which is good.

One small improvement: initFormInputsEndInvestigation keeps pushing into this.investigationInputs without clearing it, so reopening the modal will accumulate stale entries.

[spoiler]
You can defensively clear before repopulating:
    initFormInputsEndInvestigation(): void {
-        this.formData = reactive({
+        this.formData = reactive({
             endInvestigationModalContinue: new FormInput({
                 isSubmitInput: true,
                 id: 'submit-modal-continue',
             }),
         });
 
-        this.investigations.forEach((investigation: Investigation) => {
+        this.investigationInputs = [];
+        this.investigations.forEach((investigation: Investigation) => {
             const investigationId = investigation.id;
             const investigationInput = new FormInput({
                 id: `end-investigation-data-${investigationId}`,
                 name: `end-investigation-data-${investigationId}`,
                 label: this.$t('licensing.investigationStartedOn', { date: investigation.startDateDisplay() }),
                 isDisabled: Boolean(investigation.endDate),
             });
 
             this.formData[`end-investigation-data-${investigationId}`] = investigationInput;
             this.investigationInputs.push(investigationInput);
         });
    }
[/spoiler]

Also applies to: 380-388, 390-410

867-916: End‑investigation selection and submit flow are solid; optional hardening

The end‑investigation flow mirrors the unencumber click/checkbox pattern and ensures only one investigation is selected at a time by clearing other investigationInputs when one is chosen. Focus trapping across select/confirm/success states looks correct and consistent.

Optional defensive tweak: although the UI shouldn’t let you reach submitEndInvestigationWithoutEncumbrance without a selection, you could guard against a future regression by early‑returning when !this.selectedInvestigation before dispatching:
async submitEndInvestigationWithoutEncumbrance(): Promise<void> {
    this.validateAll({ asTouched: true });

    if (!this.selectedInvestigation) {
        return;
    }

    if (this.isFormValid) {
        // existing logic…
    }
}
Also applies to: 918-926, 928-947, 949-979, 985-1019
webroot/src/components/LicenseCard/LicenseCard.ts (2)
306-315: Reset investigationInputs when initializing end‑investigation form

The add/end investigation initializers are structurally correct, but initFormInputsEndInvestigation keeps appending to this.investigationInputs on each open, which can create stale entries over time.

[spoiler]
Consider clearing before repopulating:
    initFormInputsEndInvestigation(): void {
-        this.formData = reactive({
+        this.formData = reactive({
             endInvestigationModalContinue: new FormInput({
                 isSubmitInput: true,
                 id: 'submit-modal-continue',
             }),
         });
 
-        this.investigations.forEach((investigation: Investigation) => {
+        this.investigationInputs = [];
+        this.investigations.forEach((investigation: Investigation) => {
             const investigationId = investigation.id;
             const investigationInput = new FormInput({
                 id: `end-investigation-data-${investigationId}`,
                 name: `end-investigation-data-${investigationId}`,
                 label: this.$t('licensing.investigationStartedOn', { date: investigation.startDateDisplay() }),
                 isDisabled: Boolean(investigation.endDate),
             });
 
             this.formData[`end-investigation-data-${investigationId}`] = investigationInput;
             this.investigationInputs.push(investigationInput);
         });
    }
[/spoiler]

Also applies to: 388-417

812-861: End‑investigation flow for licenses looks good; optional defensive guard

The license end‑investigation flow (click handler, selection management, confirm step, focus trap, and update call) is parallel to PrivilegeCard and reuses the proven unencumber checkbox pattern. This keeps UX and behavior consistent across licenses and privileges. Based on learnings.

As with PrivilegeCard, you might optionally guard submitEndInvestigationWithoutEncumbrance against a missing selectedInvestigation to future‑proof against template changes:
async submitEndInvestigationWithoutEncumbrance(): Promise<void> {
    this.validateAll({ asTouched: true });

    if (!this.selectedInvestigation) {
        return;
    }

    if (this.isFormValid) {
        // existing logic…
    }
}
Also applies to: 863-871, 873-892, 894-919, 921-965

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a8c2f7a and c97769b.

⛔ Files ignored due to path filters (1)

backend/compact-connect/lambdas/nodejs/yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (37)

backend/compact-connect-ui-app/pipeline/frontend_pipeline.py (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/BetaFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/BetaFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/ProdFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/ProdFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json (1 hunks)
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json (1 hunks)
backend/compact-connect/lambdas/nodejs/package.json (0 hunks)
backend/compact-connect/tests/app/base.py (2 hunks)
backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json (0 hunks)
webroot/src/components/LicenseCard/LicenseCard.less (6 hunks)
webroot/src/components/LicenseCard/LicenseCard.ts (10 hunks)
webroot/src/components/LicenseCard/LicenseCard.vue (3 hunks)
webroot/src/components/PrivilegeCard/PrivilegeCard.less (7 hunks)
webroot/src/components/PrivilegeCard/PrivilegeCard.ts (13 hunks)
webroot/src/components/PrivilegeCard/PrivilegeCard.vue (3 hunks)
webroot/src/locales/en.json (1 hunks)
webroot/src/locales/es.json (1 hunks)
webroot/src/models/Investigation/Investigation.model.spec.ts (1 hunks)
webroot/src/models/Investigation/Investigation.model.ts (1 hunks)
webroot/src/models/License/License.model.spec.ts (12 hunks)
webroot/src/models/License/License.model.ts (6 hunks)
webroot/src/models/Licensee/Licensee.model.spec.ts (6 hunks)
webroot/src/models/Licensee/Licensee.model.ts (2 hunks)
webroot/src/network/data.api.ts (2 hunks)
webroot/src/network/licenseApi/data.api.ts (2 hunks)
webroot/src/network/mocks/mock.data.api.ts (2 hunks)
webroot/src/network/mocks/mock.data.ts (4 hunks)
webroot/src/pages/LicensingDetail/LicensingDetail.less (1 hunks)
webroot/src/pages/LicensingDetail/LicensingDetail.ts (3 hunks)
webroot/src/pages/LicensingDetail/LicensingDetail.vue (1 hunks)
webroot/src/store/users/users.actions.ts (2 hunks)
webroot/src/store/users/users.mutations.ts (4 hunks)
webroot/src/store/users/users.spec.ts (4 hunks)
webroot/src/styles.common/_colors.less (1 hunks)

💤 Files with no reviewable changes (2)

backend/compact-connect/lambdas/nodejs/package.json
backend/compact-connect/tests/resources/snapshots/SSN_TABLE_RESOURCE_POLICY.json

✅ Files skipped from review due to trivial changes (2)

backend/compact-connect-ui-app/tests/resources/snapshots/ProdFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/BetaFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json

🧰 Additional context used

🧠 Learnings (26)

📓 Common learnings

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1218
File: backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py:127-127
Timestamp: 2025-11-21T01:00:00.653Z
Learning: As of November 2025, AWS Lambda and LambdaEdge support Node.js 24.x runtime (Runtime.NODEJS_24_X in AWS CDK), even though official documentation may not be fully updated yet.

📚 Learning: 2025-11-06T18:11:58.272Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1196
File: webroot/src/network/mocks/mock.data.ts:1919-1944
Timestamp: 2025-11-06T18:11:58.272Z
Learning: In CompactConnect, the investigation event type (`updateType: 'investigation'`) in privilege/license history is intentionally not yet fully supported in the frontend UI translation and categorization logic (webroot/src/locales/*.json and webroot/src/models/LicenseHistoryItem/LicenseHistoryItem.model.ts). The server license history API needs to be updated first to return sufficient information about investigation events. Until then, the UI gracefully falls back to displaying "Unknown" for investigation events, which is acceptable as an interim solution.
<!--

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/store/users/users.spec.ts
webroot/src/models/License/License.model.spec.ts
webroot/src/components/LicenseCard/LicenseCard.less
webroot/src/models/Licensee/Licensee.model.spec.ts
webroot/src/network/licenseApi/data.api.ts
webroot/src/components/LicenseCard/LicenseCard.vue
webroot/src/network/data.api.ts
webroot/src/models/Investigation/Investigation.model.spec.ts
webroot/src/models/Investigation/Investigation.model.ts
webroot/src/pages/LicensingDetail/LicensingDetail.ts
webroot/src/locales/es.json
webroot/src/models/Licensee/Licensee.model.ts
webroot/src/store/users/users.mutations.ts
webroot/src/pages/LicensingDetail/LicensingDetail.vue
webroot/src/network/mocks/mock.data.ts
webroot/src/network/mocks/mock.data.api.ts
webroot/src/locales/en.json
webroot/src/components/PrivilegeCard/PrivilegeCard.vue
webroot/src/store/users/users.actions.ts
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-11-12T21:06:06.981Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1196
File: webroot/src/components/LicenseCard/LicenseCard.ts:388-396
Timestamp: 2025-11-12T21:06:06.981Z
Learning: In the CompactConnect investigation creation flow, the backend APIs for creating investigations (both `createLicenseInvestigation` and `createPrivilegeInvestigation` in webroot/src/network/licenseApi/data.api.ts) do not accept a `startDate` parameter. The backend automatically sets the investigation creation date to the timestamp when the API request is received, so the frontend UI does not need to capture or submit an investigation start date during the creation workflow.

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts
webroot/src/models/Licensee/Licensee.model.spec.ts
webroot/src/network/licenseApi/data.api.ts
webroot/src/network/data.api.ts
webroot/src/models/Investigation/Investigation.model.spec.ts
webroot/src/models/Investigation/Investigation.model.ts
webroot/src/models/Licensee/Licensee.model.ts
webroot/src/network/mocks/mock.data.ts
webroot/src/network/mocks/mock.data.api.ts
webroot/src/locales/en.json
webroot/src/store/users/users.actions.ts
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-11-06T18:14:40.626Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1196
File: webroot/src/models/Investigation/Investigation.model.ts:67-86
Timestamp: 2025-11-06T18:14:40.626Z
Learning: In the Investigation model (webroot/src/models/Investigation/Investigation.model.ts), the isActive() method intentionally includes defensive logic to handle potential backend bug states where the start date (startDate) might be missing. If an investigation record exists but lacks a start date, it should still be considered active as long as it hasn't ended (updateDate is null or in the future), because the record's existence implies it was created and just has missing date metadata.

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts
webroot/src/models/Licensee/Licensee.model.spec.ts
webroot/src/network/licenseApi/data.api.ts
webroot/src/models/Investigation/Investigation.model.spec.ts
webroot/src/models/Investigation/Investigation.model.ts
webroot/src/models/Licensee/Licensee.model.ts
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-10-29T19:11:33.003Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1167
File: backend/compact-connect/lambdas/python/provider-data-v1/handlers/investigation.py:85-95
Timestamp: 2025-10-29T19:11:33.003Z
Learning: InvestigationData extends CCDataClass which provides the licenseTypeAbbreviation property as a computed property (returns license type abbreviation if the instance has both 'compact' and 'licenseType' fields). Therefore, InvestigationData instances have access to licenseTypeAbbreviation through inheritance, and it does not need to be explicitly set when creating new investigation records.

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts
webroot/src/models/Licensee/Licensee.model.spec.ts
webroot/src/network/licenseApi/data.api.ts
webroot/src/network/data.api.ts
webroot/src/models/Investigation/Investigation.model.ts
webroot/src/pages/LicensingDetail/LicensingDetail.ts
webroot/src/models/Licensee/Licensee.model.ts
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-11-06T18:10:16.437Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1196
File: webroot/src/network/mocks/mock.data.ts:772-793
Timestamp: 2025-11-06T18:10:16.437Z
Learning: In CompactConnect, licenses and privileges can have investigations from different jurisdictions. For example, a license in Nevada (NV) can legitimately have investigations with jurisdiction Wyoming (WY). This cross-jurisdiction investigation pattern is valid in the data model and represents real-world scenarios where a practitioner licensed in one state may be under investigation by another state's authorities.

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts
webroot/src/models/Licensee/Licensee.model.spec.ts
webroot/src/network/licenseApi/data.api.ts
webroot/src/network/data.api.ts
webroot/src/models/Licensee/Licensee.model.ts
webroot/src/network/mocks/mock.data.ts
webroot/src/network/mocks/mock.data.api.ts
webroot/src/store/users/users.actions.ts

📚 Learning: 2025-08-21T15:23:26.019Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 1025
File: webroot/src/models/Licensee/Licensee.model.ts:242-254
Timestamp: 2025-08-21T15:23:26.019Z
Learning: In the CompactConnect codebase, the LicenseSerializer.fromServer() method maps the server response field `dateOfIssuance` to the License model's `issueDate` property. After serialization, License instances only contain `issueDate` and never have `dateOfIssuance`. When reviewing date comparisons in reducers that work with License objects, check if they're working with serialized License instances (which use `issueDate`) rather than raw server data (which uses `dateOfIssuance`).

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts

📚 Learning: 2025-08-21T15:23:30.649Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 1025
File: webroot/src/models/Licensee/Licensee.model.ts:242-254
Timestamp: 2025-08-21T15:23:30.649Z
Learning: In the CompactConnect frontend codebase, the LicenseSerializer.fromServer() method maps server response field `dateOfIssuance` to the License model field `issueDate`. After serialization, License objects only contain `issueDate` and never `dateOfIssuance`, so reducer logic only needs to check for null `issueDate` values.

Applied to files:

webroot/src/models/License/License.model.ts
webroot/src/models/License/License.model.spec.ts

📚 Learning: 2025-08-22T21:20:35.260Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1029
File: backend/compact-connect/docs/api-specification/latest-oas30.json:468-471
Timestamp: 2025-08-22T21:20:35.260Z
Learning: The file backend/compact-connect/docs/api-specification/latest-oas30.json is auto-generated by API Gateway and should not be modified inline. Any schema changes would need to be addressed at the source in the CDK/CloudFormation definitions.

Applied to files:

backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json
backend/compact-connect/tests/app/base.py
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/ProdFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json
backend/compact-connect-ui-app/pipeline/frontend_pipeline.py
backend/compact-connect-ui-app/tests/resources/snapshots/BetaFrontend-FrontendDeploymentStack-UI_DISTRIBUTION.json

📚 Learning: 2025-11-21T01:00:00.653Z

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1218
File: backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py:127-127
Timestamp: 2025-11-21T01:00:00.653Z
Learning: As of November 2025, AWS Lambda and LambdaEdge support Node.js 24.x runtime (Runtime.NODEJS_24_X in AWS CDK), even though official documentation may not be fully updated yet.

Applied to files:

backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json

📚 Learning: 2025-07-22T03:36:17.137Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/purchases/requirements-dev.txt:15-0
Timestamp: 2025-07-22T03:36:17.137Z
Learning: In CompactConnect, requirements-dev.txt files for Lambda functions are used exclusively for running tests and development, not for actual Lambda runtime environments. Concerns about runtime compatibility (like OpenSSL versions) don't apply to these development dependency files.

Applied to files:

backend/compact-connect-ui-app/tests/resources/snapshots/SandboxUI-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json
backend/compact-connect-ui-app/tests/resources/snapshots/TestFrontend-FrontendDeploymentStack-UI_DISTRIBUTION_LAMBDA_FUNCTION.json

📚 Learning: 2025-10-15T21:52:47.392Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1135
File: backend/compact-connect/stacks/api_lambda_stack/provider_management.py:100-0
Timestamp: 2025-10-15T21:52:47.392Z
Learning: In the CompactConnect repository, the team prefers to keep cdk-nag suppressions explicit with hard-coded logical IDs (e.g., 'Resource::<ProviderTableEC5D0597.Arn>/index/*') rather than using generic suppressions. This intentional brittleness ensures that when underlying resources change, the suppressions break and force manual review of the IAM policies.

Applied to files:

backend/compact-connect/tests/app/base.py

📚 Learning: 2025-10-09T21:11:36.590Z

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1143
File: backend/compact-connect/tests/app/base.py:514-530
Timestamp: 2025-10-09T21:11:36.590Z
Learning: In the BackendStage class within the CompactConnect backend infrastructure, the following stacks are always required and their absence indicates a serious error: api_lambda_stack, api_stack, disaster_recovery_stack, event_listener_stack, feature_flag_stack, ingest_stack, managed_login_stack, persistent_stack, provider_users_stack, state_api_stack, state_auth_stack, and transaction_monitoring_stack. Only backup_infrastructure_stack can be None (when backups are disabled). The reporting_stack and notification_stack are conditionally present based on hosted_zone configuration.

Applied to files:

backend/compact-connect/tests/app/base.py

📚 Learning: 2025-06-04T20:07:09.680Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 824
File: backend/compact-connect/tests/app/test_event_listener.py:29-222
Timestamp: 2025-06-04T20:07:09.680Z
Learning: In the CompactConnect project, test methods that include property snapshots for different AWS resource configurations (like event listeners) should be kept decoupled rather than extracted into common helper methods, even if they appear similar. This avoids complex parameter passing and maintains test independence when snapshots may vary between configurations.

Applied to files:

backend/compact-connect/tests/app/base.py

📚 Learning: 2025-07-21T20:53:14.686Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/multi-account/backups/stacks/backup_account_stack.py:241-263
Timestamp: 2025-07-21T20:53:14.686Z
Learning: In CompactConnect, landonshumway-ia explained that the SSN backup vault DENY policy using 'ForAnyValue:ArnNotEquals' with 'backup:CopyTargets' correctly prevents the vault from being used as a source for copying to other vaults. The policy implements a "data check-in but no check-out" security model where sensitive SSN backups can be copied into the vault but not copied out to external destinations under normal circumstances.

Applied to files:

backend/compact-connect/tests/app/base.py

📚 Learning: 2025-07-08T18:40:24.408Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 882
File: backend/compact-connect/lambdas/python/common/cc_common/data_model/compact_configuration_client.py:287-359
Timestamp: 2025-07-08T18:40:24.408Z
Learning: In the CompactConnect codebase, landonshumway-ia prefers to avoid extraneous unit tests when existing test coverage is already sufficient to catch bugs. For the get_privilege_purchase_options method's live-jurisdiction filtering logic, the existing tests in the purchases test suite provide adequate coverage without needing additional edge case tests.

Applied to files:

webroot/src/store/users/users.spec.ts
webroot/src/models/Licensee/Licensee.model.spec.ts

📚 Learning: 2025-08-29T18:16:12.078Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1042
File: webroot/src/store/user/user.mutations.ts:269-272
Timestamp: 2025-08-29T18:16:12.078Z
Learning: The CONFIRM_MFA_LICENSEE_ACCOUNT_REQUEST mutation intentionally sets isLoadingAccount = false (rather than true like other REQUEST mutations) because the MfaResetConfirmLicensee page handles its own loading UI with a custom LoadingSpinner component and isLoading state, rather than triggering the global app loading state.

Applied to files:

webroot/src/store/users/users.spec.ts
webroot/src/store/users/users.mutations.ts

📚 Learning: 2025-08-12T22:51:48.937Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 1009
File: webroot/src/pages/LicenseeProof/LicenseeProof.less:158-165
Timestamp: 2025-08-12T22:51:48.937Z
Learning: In webroot/src/pages/LicenseeProof/LicenseeProof.vue, the .max-gap elements inside .licenses-container are intentionally hard-coded as empty elements that serve as space placeholders for tablet+ screen widths. On mobile, they are hidden completely using the :empty pseudo-class. This is an intentional design pattern where the developers have full control over keeping these elements truly empty.

Applied to files:

webroot/src/pages/LicensingDetail/LicensingDetail.less
webroot/src/components/LicenseCard/LicenseCard.less
webroot/src/components/LicenseCard/LicenseCard.vue
webroot/src/pages/LicensingDetail/LicensingDetail.vue
webroot/src/components/PrivilegeCard/PrivilegeCard.vue

📚 Learning: 2025-08-20T17:27:40.673Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 1009
File: webroot/src/models/License/License.model.spec.ts:599-601
Timestamp: 2025-08-20T17:27:40.673Z
Learning: The `dateDisplay` utility function in the License model can handle both date-only strings (serverDateFormat) and datetime strings (serverDatetimeFormat) correctly. When testing date display methods like `activeFromDateDisplay()`, use the format that matches the expected parsing behavior rather than the input format.

Applied to files:

webroot/src/models/License/License.model.spec.ts

📚 Learning: 2025-06-24T00:02:39.944Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 873
File: webroot/src/components/LicenseCard/LicenseCard.ts:414-443
Timestamp: 2025-06-24T00:02:39.944Z
Learning: In LicenseCard component's clickUnencumberItem method (webroot/src/components/LicenseCard/LicenseCard.ts), complex event handling for checkbox interactions is intentionally designed to ensure consistent behavior across checkbox input, wrapper label, and outer selection parent elements for custom UI requirements. This complexity should be preserved rather than simplified.

Applied to files:

webroot/src/components/LicenseCard/LicenseCard.less
webroot/src/components/LicenseCard/LicenseCard.vue
webroot/src/pages/LicensingDetail/LicensingDetail.ts
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-08-21T16:36:48.723Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1019
File: webroot/src/components/PrivilegeCard/PrivilegeCard.vue:270-278
Timestamp: 2025-08-21T16:36:48.723Z
Learning: In PrivilegeCard component's unencumber modal (webroot/src/components/PrivilegeCard/PrivilegeCard.vue), the unencumber-select wrapper element intentionally uses space key handling to catch bubbled events from child InputCheckbox elements for custom handling actions. When adverseAction.hasEndDate() is true, items show an inactive-category div and are designed to be non-interactive (not focusable), while items without end dates contain focusable InputCheckbox child elements. This design pattern is consistent with prior implementation and represents intentional UX behavior.

Applied to files:

webroot/src/components/LicenseCard/LicenseCard.less
webroot/src/components/PrivilegeCard/PrivilegeCard.less
webroot/src/components/LicenseCard/LicenseCard.vue
webroot/src/pages/LicensingDetail/LicensingDetail.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.vue
webroot/src/components/LicenseCard/LicenseCard.ts
webroot/src/components/PrivilegeCard/PrivilegeCard.ts

📚 Learning: 2025-07-22T03:52:25.934Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Applied to files:

backend/compact-connect-ui-app/pipeline/frontend_pipeline.py

📚 Learning: 2025-07-03T15:35:57.893Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 905
File: webroot/src/components/UpdateHomeJurisdiction/UpdateHomeJurisdiction.vue:32-41
Timestamp: 2025-07-03T15:35:57.893Z
Learning: In the CompactConnect frontend codebase, the team prefers to keep non-dynamic text directly in Vue templates rather than moving it to computed properties in TypeScript modules, as this approach prevents cluttering the TS files with template labels.

Applied to files:

webroot/src/pages/LicensingDetail/LicensingDetail.ts

📚 Learning: 2025-08-29T17:54:57.683Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 1042
File: webroot/src/locales/es.json:958-958
Timestamp: 2025-08-29T17:54:57.683Z
Learning: Spanish translations in webroot/src/locales/es.json are currently generated using Google Translate and are considered nice-to-have. The team plans to use professional translation services if formal Spanish support is needed in the future. Don't spend time on nuanced translation quality issues for Spanish locale files.

Applied to files:

webroot/src/locales/es.json

📚 Learning: 2025-06-09T19:57:51.519Z

Learnt from: rmolinares
Repo: csg-org/CompactConnect PR: 851
File: webroot/src/pages/RegisterLicensee/RegisterLicensee.ts:0-0
Timestamp: 2025-06-09T19:57:51.519Z
Learning: In the RegisterLicensee component, when handling DOM element availability issues, the developer prefers using Vue Watchers over retry mechanisms with requestAnimationFrame to avoid infinite recursion risks and maintain Vue's reactive patterns.

Applied to files:

webroot/src/pages/LicensingDetail/LicensingDetail.vue

📚 Learning: 2025-07-10T19:52:40.366Z

Learnt from: jsandoval81
Repo: csg-org/CompactConnect PR: 922
File: webroot/src/components/UserAccount/UserAccount.ts:250-267
Timestamp: 2025-07-10T19:52:40.366Z
Learning: In focus trap implementations for modals, when there's only one focusable element (like in a success state), it's correct for both firstTabIndex and lastTabIndex to reference the same element. This keeps focus appropriately trapped on that single element. Optional chaining operators (?.focus()) provide adequate null safety for DOM element access in focus management code.

Applied to files:

webroot/src/components/PrivilegeCard/PrivilegeCard.ts

🧬 Code graph analysis (15)

webroot/src/models/License/License.model.ts (1)

webroot/src/models/Investigation/Investigation.model.ts (2)

Investigation (33-93)

InvestigationSerializer (98-113)

webroot/src/store/users/users.spec.ts (1)

webroot/src/store/users/users.state.ts (1)

state (17-24)

webroot/src/models/License/License.model.spec.ts (2)

webroot/src/models/Investigation/Investigation.model.ts (1)

Investigation (33-93)

webroot/src/app.config.ts (1)

serverDateFormat (157-157)

webroot/src/models/Licensee/Licensee.model.spec.ts (4)

webroot/src/models/License/License.model.ts (1)

License (73-193)

webroot/src/models/Investigation/Investigation.model.ts (1)

Investigation (33-93)

webroot/src/app.config.ts (1)

serverDateFormat (157-157)

webroot/src/models/Licensee/Licensee.model.ts (1)

Licensee (64-397)

webroot/src/network/licenseApi/data.api.ts (6)

webroot/src/pages/LicensingDetail/LicensingDetail.ts (2)

compact (63-67)

licenseeId (92-94)

webroot/src/pages/PublicLicensingDetail/PublicLicensingDetail.ts (2)

compact (51-55)

licenseeId (57-59)

webroot/src/pages/PrivilegeDetail/PrivilegeDetail.ts (2)

compact (83-87)

licenseeId (75-77)

webroot/src/pages/PublicPrivilegeDetail/PublicPrivilegeDetail.ts (2)

compact (60-62)

licenseeId (56-58)

webroot/src/components/LicenseCard/LicenseCard.ts (1)

licenseeId (147-149)

webroot/src/components/PrivilegeCard/PrivilegeCard.ts (1)

licenseeId (135-137)

webroot/src/network/data.api.ts (1)

webroot/src/network/licenseApi/data.api.ts (1)

licenseDataApi (641-641)

webroot/src/models/Investigation/Investigation.model.spec.ts (2)

webroot/src/models/Investigation/Investigation.model.ts (2)

Investigation (33-93)

InvestigationSerializer (98-113)

webroot/src/app.config.ts (2)

serverDateFormat (157-157)

displayDateFormat (163-163)

webroot/src/models/Investigation/Investigation.model.ts (2)

webroot/src/models/_helpers/index.ts (1)

deleteUndefinedProperties (24-24)

webroot/src/app.config.ts (1)

serverDateFormat (157-157)

webroot/src/models/Licensee/Licensee.model.ts (3)

webroot/src/models/License/License.model.ts (1)

License (73-193)

webroot/src/models/State/State.model.ts (1)

State (21-49)

webroot/src/models/Investigation/Investigation.model.ts (1)

Investigation (33-93)

webroot/src/store/users/users.mutations.ts (1)

webroot/src/store/users/users.state.ts (1)

state (17-24)

webroot/src/network/mocks/mock.data.ts (1)

webroot/src/app.config.ts (2)

serverDatetimeFormat (158-158)

serverDateFormat (157-157)

webroot/src/network/mocks/mock.data.api.ts (6)

webroot/src/pages/LicensingDetail/LicensingDetail.ts (2)

compact (63-67)

licenseeId (92-94)

webroot/src/pages/PublicLicensingDetail/PublicLicensingDetail.ts (2)

compact (51-55)

licenseeId (57-59)

webroot/src/pages/PrivilegeDetail/PrivilegeDetail.ts (2)

compact (83-87)

licenseeId (75-77)

webroot/src/pages/PublicPrivilegeDetail/PublicPrivilegeDetail.ts (2)

compact (60-62)

licenseeId (56-58)

webroot/src/components/LicenseCard/LicenseCard.ts (1)

licenseeId (147-149)

webroot/src/components/PrivilegeCard/PrivilegeCard.ts (1)

licenseeId (135-137)

webroot/src/store/users/users.actions.ts (5)

webroot/src/network/data.api.ts (1)

dataApi (689-689)

webroot/src/network/mocks/mock.data.api.ts (1)

dataApi (809-809)

webroot/src/pages/LicensingDetail/LicensingDetail.ts (2)

compact (63-67)

licenseeId (92-94)

webroot/src/components/LicenseCard/LicenseCard.ts (1)

licenseeId (147-149)

webroot/src/components/PrivilegeCard/PrivilegeCard.ts (1)

licenseeId (135-137)

webroot/src/components/LicenseCard/LicenseCard.ts (4)

webroot/src/models/FormInput/FormInput.model.ts (1)

FormInput (59-170)

webroot/src/models/AdverseAction/AdverseAction.model.ts (1)

AdverseAction (35-122)

webroot/src/models/Investigation/Investigation.model.ts (1)

Investigation (33-93)

webroot/src/components/Forms/InputCheckbox/InputCheckbox.ts (1)

input (26-34)

webroot/src/components/PrivilegeCard/PrivilegeCard.ts (4)

webroot/src/models/FormInput/FormInput.model.ts (2)

FormInput (59-170)

input (109-117)

webroot/src/models/Investigation/Investigation.model.ts (1)

Investigation (33-93)

webroot/src/components/LicenseCard/LicenseCard.ts (1)

isEndInvestigationSubmitEnabled (295-297)

webroot/src/components/Forms/InputCheckbox/InputCheckbox.ts (1)

input (26-34)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

GitHub Check: TestApp
GitHub Check: CheckWebroot
GitHub Check: TestApp

webroot/src/models/Investigation/Investigation.model.ts

webroot/src/models/Licensee/Licensee.model.ts

coderabbitai

Actionable comments posted: 1

🧹 Nitpick comments (2)

.github/workflows/check-compact-connect-ui-app.yml (1)

49-49: Consider updating actions/setup-node@v1 to a newer version.

The actions/setup-node@v1 action is outdated. While this is a pre-existing issue, consider updating it to v4 to align with current GitHub Actions best practices. This applies to line 49 and line 87 as well.

.github/workflows/check-compact-connect.yml (1)

49-49: Pre-existing: Consider updating actions/setup-node@v1 in other jobs.

Similar to the file-level concern in .github/workflows/check-compact-connect-ui-app.yml, the actions/setup-node@v1 action on line 49 (and line 87 in this file's TestApp job) should be updated to v4 as part of a broader modernization effort, though this is a pre-existing issue separate from the runtime upgrade scope.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c97769b and 5dcf516.

📒 Files selected for processing (9)

.github/workflows/check-common-cdk.yml (2 hunks)
.github/workflows/check-compact-connect-ui-app.yml (3 hunks)
.github/workflows/check-compact-connect.yml (4 hunks)
backend/compact-connect-ui-app/requirements-dev.txt (3 hunks)
backend/compact-connect-ui-app/requirements.txt (2 hunks)
backend/compact-connect/bin/run_python_tests.py (1 hunks)
backend/compact-connect/lambdas/python/purchases/.coveragerc (1 hunks)
backend/compact-connect/lambdas/python/purchases/requirements-dev.in (1 hunks)
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt (6 hunks)

✅ Files skipped from review due to trivial changes (1)

backend/compact-connect/lambdas/python/purchases/.coveragerc

🧰 Additional context used

🧠 Learnings (10)

📓 Common learnings

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Learnt from: jusdino
Repo: csg-org/CompactConnect PR: 1218
File: backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py:127-127
Timestamp: 2025-11-21T01:00:00.653Z
Learning: As of November 2025, AWS Lambda and LambdaEdge support Node.js 24.x runtime (Runtime.NODEJS_24_X in AWS CDK), even though official documentation may not be fully updated yet.

📚 Learning: 2025-07-22T03:52:25.934Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/provider-data-v1/requirements.txt:2-2
Timestamp: 2025-07-22T03:52:25.934Z
Learning: In CompactConnect, the Python version used by pip-compile to generate requirements.txt files (shown in the header comment) is separate from the actual Lambda runtime environment. Dependencies are installed by a Python 3.12 container during the CI/CD pipeline, ensuring runtime compatibility regardless of the Python version used for pip-compile dependency resolution.

Applied to files:

.github/workflows/check-compact-connect.yml
backend/compact-connect-ui-app/requirements-dev.txt
.github/workflows/check-compact-connect-ui-app.yml
backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-07-22T03:36:17.137Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/purchases/requirements-dev.txt:15-0
Timestamp: 2025-07-22T03:36:17.137Z
Learning: In CompactConnect, requirements-dev.txt files for Lambda functions are used exclusively for running tests and development, not for actual Lambda runtime environments. Concerns about runtime compatibility (like OpenSSL versions) don't apply to these development dependency files.

Applied to files:

backend/compact-connect-ui-app/requirements-dev.txt
backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-08-21T02:51:28.199Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1014
File: backend/compact-connect/lambdas/python/common/requirements.in:4-4
Timestamp: 2025-08-21T02:51:28.199Z
Learning: In CompactConnect, the purchases lambda contains requests as a transitive dependency from the Authorize.net SDK, which is automatically resolved by pip-compile. This should not be manually removed even when requests is also available in the common layer, as it's managed automatically by the dependency resolver.

Applied to files:

backend/compact-connect/bin/run_python_tests.py
backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-07-08T18:40:24.408Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 882
File: backend/compact-connect/lambdas/python/common/cc_common/data_model/compact_configuration_client.py:287-359
Timestamp: 2025-07-08T18:40:24.408Z
Learning: In the CompactConnect codebase, landonshumway-ia prefers to avoid extraneous unit tests when existing test coverage is already sufficient to catch bugs. For the get_privilege_purchase_options method's live-jurisdiction filtering logic, the existing tests in the purchases test suite provide adequate coverage without needing additional edge case tests.

Applied to files:

backend/compact-connect/bin/run_python_tests.py

📚 Learning: 2025-08-25T19:04:48.800Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1014
File: backend/compact-connect/lambdas/python/provider-data-v1/tests/function/test_handlers/test_account_recovery.py:288-293
Timestamp: 2025-08-25T19:04:48.800Z
Learning: In the CompactConnect project, landonshumway-ia has already provided feedback on patch cleanup patterns in test setup methods for the account recovery tests, so similar suggestions about stopping patches in setUp/tearDown should not be repeated.

Applied to files:

backend/compact-connect/bin/run_python_tests.py

📚 Learning: 2025-08-12T19:49:48.235Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/lambdas/python/disaster-recovery/requirements.txt:1-6
Timestamp: 2025-08-12T19:49:48.235Z
Learning: The disaster-recovery Lambda functions in CompactConnect get their aws-lambda-powertools dependency from the shared lambda layer rather than individual requirements.txt files, which is why their requirements.txt files can be empty or header-only.

Applied to files:

backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-08-12T19:49:24.999Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1001
File: backend/compact-connect/lambdas/python/disaster-recovery/requirements.in:1-1
Timestamp: 2025-08-12T19:49:24.999Z
Learning: In CompactConnect disaster-recovery Lambda functions, runtime dependencies like boto3, aws-lambda-powertools, and botocore are provided by lambda layers at deploy time rather than being specified in requirements.in files. The requirements.in file intentionally contains only a comment explaining this approach.

Applied to files:

backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in
backend/compact-connect/lambdas/python/purchases/requirements-dev.txt

📚 Learning: 2025-08-22T21:20:35.260Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 1029
File: backend/compact-connect/docs/api-specification/latest-oas30.json:468-471
Timestamp: 2025-08-22T21:20:35.260Z
Learning: The file backend/compact-connect/docs/api-specification/latest-oas30.json is auto-generated by API Gateway and should not be modified inline. Any schema changes would need to be addressed at the source in the CDK/CloudFormation definitions.

Applied to files:

backend/compact-connect-ui-app/requirements.txt

📚 Learning: 2025-07-21T20:40:56.491Z

Learnt from: landonshumway-ia
Repo: csg-org/CompactConnect PR: 907
File: backend/compact-connect/lambdas/python/common/requirements.txt:7-0
Timestamp: 2025-07-21T20:40:56.491Z
Learning: In CompactConnect, there is only one lambda layer in use for Python lambdas, and this single layer manages the versions of aws-lambda-powertools, boto3, and botocore dependencies. This eliminates concerns about version skew across multiple lambda layers since all Python lambdas share the same dependency management through this single layer.

Applied to files:

backend/compact-connect-ui-app/requirements.txt
backend/compact-connect/lambdas/python/purchases/requirements-dev.in

🪛 actionlint (1.7.8)

.github/workflows/check-compact-connect.yml

87-87: the runner of "actions/setup-node@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

119-119: the runner of "actions/checkout@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

.github/workflows/check-compact-connect-ui-app.yml

87-87: the runner of "actions/setup-node@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🔇 Additional comments (11)

backend/compact-connect-ui-app/requirements.txt (2)

2-2: Verify pip-compile command path change and typeguard major version upgrade.

Two concerns:

pip-compile command path change (line 5): The command changed from compact-connect/requirements.in to requirements.in, suggesting a file path restructuring. Verify this aligns with the actual location of requirements.in and confirm the CI/CD pipeline's working directory assumptions are updated accordingly.

typeguard major version upgrade (line 61): The jump from 2.13.3 to 4.2.1 is a major version change (2.x → 4.x), which may introduce breaking changes. Verify that all code relying on typeguard's API (especially runtime type checking) is compatible with the new version, and review the typeguard changelog for migration notes.

Also applies to: 5-5

1-71: Approve Python 3.14 runtime upgrade and dependency pins.

The Python version bump to 3.14 (line 2) aligns with the PR objective to remediate CVEs and upgrade runtimes. The dependency version updates are appropriate, with AWS CDK packages upgraded from 2.212 to 2.227, and other libraries receiving patch/minor updates. These changes support the broader runtime and dependency modernization goals of the PR.

Note: This is an auto-generated file. Verify that the actual source edits were made to requirements.in (as referenced in line 5's pip-compile command), not to this file directly.

.github/workflows/check-common-cdk.yml (1)

22-22: Version upgrades align with PR objectives.

Python runtime bumped to 3.14 across both jobs (LintPython and TestApp), consistent with the migration away from 3.12. The pip vulnerability exemption on line 34 remains valid for Python 3.14+.

Also applies to: 46-46

.github/workflows/check-compact-connect-ui-app.yml (1)

22-22: Runtime versions updated consistently across jobs.

Python bumped to 3.14 and Node.js to 24.11.1 across LintPython, LintNode, and TestApp jobs, aligning with the PR's migration objectives. Per learnings, Node.js 24.x is supported by AWS Lambda as of November 2025.

Also applies to: 51-51, 83-83, 89-89

.github/workflows/check-compact-connect.yml (1)

22-22: Runtime versions upgraded consistently.

Python to 3.14 and Node.js to 24.11.1 across LintPython, LintNode, and TestApp jobs, aligned with PR objectives. The pip version pinning workaround (lines 104–106) is appropriately documented.

Also applies to: 51-51, 83-83, 89-89

backend/compact-connect/bin/run_python_tests.py (1)

36-37: LGTM: Purchases tests appropriately excluded from unified test run.

The exclusion of purchases from run_python_tests.py is well-justified and properly implemented. The separate TestAndLintPurchases workflow handles purchases testing independently with Python 3.12, accommodating the Authorize.net dependency constraints. The purchases lambda has comprehensive test coverage with 7 test files (handler and unit tests) and enforced 90% coverage threshold, ensuring adequate verification despite the separate execution path.

backend/compact-connect-ui-app/requirements-dev.txt (3)

2-5: Python version bump to 3.14 aligns with PR objectives.

The header now reflects Python 3.14 for pip-compile dependency resolution, consistent with the runtime upgrade objectives in PR #1216. Per project learnings, this pip-compile version is independent of the actual Lambda runtime environment.

23-23: Path adjustment is correct—no issues found.

The verification confirms that requirements-dev.in exists in backend/compact-connect-ui-app/ and the old reference path compact-connect/requirements-dev.in does not exist. The changes from compact-connect/requirements-dev.in to requirements-dev.in correctly reflect the actual file structure.

77-77: Verify that pytest and ruff versions work correctly by running the CI workflow or local test execution before merging.

Breaking changes exist in both pytest 9.0 (collection order, warns() re-emission, error handling) and ruff 0.14 (Python target version). However, analysis shows:

The ruff.toml explicitly targets Python 3.12, which overrides ruff 0.14's new default targeting Python 3.14, eliminating that incompatibility.

The codebase has no custom pytest plugins, parser.addini configuration, or warning-to-error conversions that would be affected by pytest 9.0's breaking changes.

The CI workflow is already configured with these versions, so test execution via the workflow will confirm compatibility.

Recommendation: Let the GitHub Actions workflow run on this PR to confirm all tests pass with the upgraded versions. No configuration changes appear necessary based on code examination.

backend/compact-connect/lambdas/python/purchases/requirements-dev.txt (1)

1-179: LGTM! Dependency updates align with runtime upgrade objectives.

The dependency version updates are substantial and appropriate for this runtime upgrade PR. Key observations:

The pip-compile Python version now aligns with the purchases lambda runtime (3.12), improving consistency even though technically separate per learnings.

Security-related packages like cryptography (46.0.3), boto3 (1.40.76), and botocore (1.40.76) have been updated to recent versions.

All locked versions fall within the ranges specified in requirements-dev.in.

Based on learnings.

backend/compact-connect/lambdas/python/purchases/requirements-dev.in (1)

9-16: LGTM! Runtime-specific layer architecture ensures Python compatibility.

The common lambda layer is already built with runtime-specific versions via PythonCommonLayerVersions. The CDK construct creates separate PythonLayerVersion builds for each runtime (Python 3.12 and 3.14), with each using the appropriate Docker image for bundling. The purchases lambda (Python 3.12) receives a 3.12-built layer, and other lambdas (Python 3.14) receive a 3.14-built layer. The version ranges in requirements-dev.in are correct and compatible.

.github/workflows/check-compact-connect.yml

landonshumway-ia

Looks great! Thank you so much for keeping this project up to date! I just saw one point in the docs that needs to be clarified.

backend/compact-connect/README.md

landonshumway-ia

Looks great.

landonshumway-ia · 2025-11-25T16:58:29Z

@jlkravitz This is ready for your review, and will be needed in order for our OpenSearch resources to run on the latest available version, so the sooner we can get it pulled in the better. Thanks

jlkravitz

Sorry for the holiday delay- one question about a specific file but otherwise this looks good to me.

backend/compact-connect/docs/signature_auth_examples.txt

jlkravitz

@isabeleliassen Good to merge!

backend/compact-connect/docs/signature_auth_examples.txt

jusdino added 5 commits November 19, 2025 09:27

Add client signature example data

4f6e962

Move comment to valid location

22d3d80

Remove unneeded example-generation test

6e7a3fc

Upgrade Python runtimes to 3.14

b6cd4e2

Upgrade backend to Node 24

a8c2f7a

jusdino requested a review from landonshumway-ia November 20, 2025 22:18

coderabbitai bot reviewed Nov 20, 2025

View reviewed changes

backend/compact-connect-ui-app/stacks/frontend_deployment_stack/distribution.py Show resolved Hide resolved

backend/compact-connect/pipeline/backend_pipeline.py Outdated Show resolved Hide resolved

jusdino and others added 3 commits November 20, 2025 17:43

Remove aws-lambda dependency (csg-org#1213)

6251ef4

### Description List - Addressing the Node CVE in an indirect dependency ### Testing List - Code review - Integrate test with some email events in *test* Closes csg-org#1205

Downgrade CodeBuild runtimes, revise tests

c97769b

coderabbitai bot reviewed Nov 21, 2025

View reviewed changes

webroot/src/models/Investigation/Investigation.model.ts Show resolved Hide resolved

webroot/src/models/Licensee/Licensee.model.ts Show resolved Hide resolved

jusdino added 3 commits November 21, 2025 14:12

Upgrade cdk and deps

d60b502

Upgrade GH actions, isolate purchases checks

e2eec84

Fix GH action paths

5dcf516

coderabbitai bot reviewed Nov 21, 2025

View reviewed changes

.github/workflows/check-compact-connect.yml Show resolved Hide resolved

jusdino added 3 commits November 21, 2025 16:19

Fix typo in test dates

450f94b

Merge branch 'main' into feat/runtime-upgrades

2b16f7b

Upgrade action versions

92222b4

landonshumway-ia requested changes Nov 25, 2025

View reviewed changes

backend/compact-connect/README.md Outdated Show resolved Hide resolved

PR feedback

68f813e

landonshumway-ia approved these changes Nov 25, 2025

View reviewed changes

landonshumway-ia requested a review from jlkravitz November 25, 2025 16:56

jlkravitz reviewed Dec 2, 2025

View reviewed changes

backend/compact-connect/docs/signature_auth_examples.txt Show resolved Hide resolved

jlkravitz approved these changes Dec 2, 2025

View reviewed changes

backend/compact-connect/docs/signature_auth_examples.txt Show resolved Hide resolved

isabeleliassen merged commit 4058377 into csg-org:main Dec 2, 2025
8 of 9 checks passed

jusdino deleted the feat/runtime-upgrades branch December 2, 2025 21:30

coderabbitai bot mentioned this pull request Dec 3, 2025

Add Search API with OpenSearch Domain and VPC Resources #1219

Merged

Feat/runtime upgrades #1218

Feat/runtime upgrades #1218

Uh oh!

Conversation

jusdino commented Nov 20, 2025 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description List

Testing List

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related PRs

Suggested reviewers

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

landonshumway-ia left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

landonshumway-ia left a comment

Choose a reason for hiding this comment

Uh oh!

landonshumway-ia commented Nov 25, 2025

Uh oh!

jlkravitz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jlkravitz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jusdino commented Nov 20, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Nov 20, 2025 •

edited

Loading

jlkravitz left a comment •

edited

Loading