fix(pds-core): redact request_uri from CSS middleware log - #80
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code review is billed via overage credits. To resume reviews, an organization admin can raise the monthly limit at claude.ai/admin-settings/claude-code.
Once credits are available, reopen this pull request to trigger a review.
📝 WalkthroughWalkthroughThe changes add Coveralls coverage thresholds and replace a logged request URI value with a boolean presence indicator in client CSS injection error handling. ChangesCoverage configuration
Error logging metadata
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed: private package registry requires authentication. Disable ESLint in CodeRabbit settings or use public packages. 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. Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
🚅 Deployed to the ePDS-pr-80 environment in ePDS
|
Coverage Report for CI Build 29371698031Coverage remained the same at 56.404%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
|
request_uri is an opaque PAR handle that should not be logged verbatim. Log only its presence for debugging. Addresses CodeRabbit review on PR #48. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Allow up to 0.05% coverage drop per PR to absorb measurement jitter, and set 32.3% absolute floor to prevent unbounded ratchet drift. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
5991f75 to
0dfb6cd
Compare
|
|
There was a problem hiding this comment.
Pull request overview
This PR tightens log hygiene in pds-core by ensuring the CSS injection middleware no longer logs opaque PAR request_uri values, while also adding a Coveralls configuration to enforce coverage-related CI thresholds.
Changes:
- Redact raw PAR
request_urifrom the CSS middleware warning log (log only presence viahasRequestUri). - Add
.coveralls.ymlto configure Coveralls coverage thresholds for CI reporting.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| packages/pds-core/src/lib/client-css-injection.ts | Replaces logging of raw requestUri with a boolean presence flag in the error path. |
| .coveralls.yml | Introduces Coveralls thresholds for coverage decrease tolerance and failure gating. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.coveralls.yml:
- Around line 1-2: Remove the coverage_decreased_threshold and
coverage_threshold_for_failure entries from .coveralls.yml, leaving only
supported Coveralls configuration there. Configure both coverage thresholds
through the Coveralls repository settings or API so the intended coverage gate
is enforced.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 59479769-9c8a-4e7b-95eb-16d97dd157fd
📒 Files selected for processing (2)
.coveralls.ymlpackages/pds-core/src/lib/client-css-injection.ts
| coverage_decreased_threshold: 0.05 | ||
| coverage_threshold_for_failure: 32.3 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== .coveralls.yml =="
if [ -f .coveralls.yml ]; then
cat -n .coveralls.yml
fi
echo
echo "== Search for coveralls references =="
rg -n --hidden -S "coveralls|coverage_decreased_threshold|coverage_threshold_for_failure|commit_status_fail_threshold|commit_status_fail_change_threshold" .
echo
echo "== Relevant CI workflow files =="
fd -a -t f '.github/workflows' .Repository: hypercerts-org/ePDS
Length of output: 895
🌐 Web query:
site:docs.coveralls.io coverage_decreased_threshold coverage_threshold_for_failure .coveralls.yml
💡 Result:
The settings for controlling build failures based on coverage metrics in Coveralls are configured via the Coveralls web interface rather than through the.coveralls.yml file [1][2]. In the Coveralls UI, you can manage these thresholds under the repository settings for Status Updates [1][2]. The relevant configurations are: 1. Coverage Threshold for Failure: This defines the minimum coverage percentage required for a build to pass [3]. 2. Coverage Decrease Threshold for Failure (often referred to as the "Decrease threshold"): This sets the maximum allowable decrease in coverage from the previous build before a failure is triggered [1][3]. While the.coveralls.yml file is used to configure integration-specific variables (such as repo_token, service_name, or branch) [4], it does not natively support setting these specific failure thresholds. These thresholds are handled by the Coveralls backend API, which processes incoming build data and reports status updates (such as "failed" or "passed") back to your Git provider (e.g., GitHub) based on the settings defined in the web UI [1][3]. If you are using the Coveralls API directly, these settings correspond to the following parameters on the /repos endpoint [3]: - commit_status_fail_threshold [3] - commit_status_fail_change_threshold [3]
Citations:
- 1: https://docs.coveralls.io/app-notifications
- 2: https://docs.coveralls.io/app-ui
- 3: https://docs.coveralls.io/api-repos-endpoint
- 4: https://docs.coveralls.io/ci-services
🌐 Web query:
"coverage_decreased_threshold" Coveralls repository status settings API
💡 Result:
The setting you are referring to is managed through the Coveralls API via the commit_status_fail_change_threshold parameter [1][2]. This setting corresponds to the "Coverage Decrease Threshold for Failure" option found in the repository settings page on the Coveralls web interface [3]. When using the Coveralls /repos API endpoint, you can configure this threshold to control build failure behavior [1][4]: - API Parameter: repo[commit_status_fail_change_threshold] [1] - Purpose: Defines the maximum allowed percentage decrease in coverage before a build is marked as failed [1][3]. - Default: null (which defaults to failure on any decrease) [1]. You can interact with this setting by sending a POST or PUT request to the repository endpoint [1][4]. Below is a summary of the relevant API fields for repository configuration: - commit_status_fail_threshold: Sets the absolute minimum coverage percentage required for a build to pass [1][5]. - commit_status_fail_change_threshold: Sets the tolerance for coverage decreases (e.g., if set to 1.0, a decrease of less than 1% will not cause the build to fail) [1][3][5]. These settings ensure that pull request status checks only block when the specified coverage drop thresholds are exceeded [3][6]. If you are automating this process, the same parameters can be used programmatically to update your repository configuration [4].
Citations:
- 1: https://docs.coveralls.io/api-repos-endpoint
- 2: https://github.com/bconnorwhite/coveralls-api
- 3: Coverall failure check on PR, can it be configured to happen below a certain delta lemurheavy/coveralls-public#1616
- 4: Coverage threshold for failure as input to gha coverallsapp/github-action#161
- 5: https://github.com/loadsmart/go-coveralls-api/blob/3fcfbe438cc4ac51604899bff950ec61190ccf43/repositories.go
- 6: Coveralls doesn't block PR if test coverage decreased lemurheavy/coveralls-public#1623
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Try to identify any local docs or config schema references for these keys.
rg -n --hidden -S "coverage_decreased_threshold|coverage_threshold_for_failure|commit_status_fail_threshold|commit_status_fail_change_threshold" . || true
# Show the repository workflows mentioning Coveralls.
rg -n --hidden -S "coverallsapp/github-action|coveralls" .github . || trueRepository: hypercerts-org/ePDS
Length of output: 413
Move the coverage thresholds to Coveralls settings.
coverage_decreased_threshold and coverage_threshold_for_failure belong in Coveralls repository settings/API, not .coveralls.yml, so this file won’t enforce the intended coverage gate. Remove them here and set the thresholds through Coveralls instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.coveralls.yml around lines 1 - 2, Remove the coverage_decreased_threshold
and coverage_threshold_for_failure entries from .coveralls.yml, leaving only
supported Coveralls configuration there. Configure both coverage thresholds
through the Coveralls repository settings or API so the intended coverage gate
is enforced.
|
Found 58 test failures on Blacksmith runners: Failures
|
Summary
request_urivalues in the CSS injection middleware's warn log. Log only presence (hasRequestUri: true) since the URI is an opaque short-lived handle.Addresses CodeRabbit review comment on PR #48: #48 (comment)
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Chores