fix(dashboard): plural counts, secret field styling, warn notes and guardrail docs - #958
fix(dashboard): plural counts, secret field styling, warn notes and guardrail docs#958SantiagoDePolonia wants to merge 3 commits into
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
|
Warning Review limit reachedNext included review available in 16 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (11)
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 |
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
| { | ||
| Key: "message", Label: "Message", Input: pluginapi.InputText, Default: DefaultMessage, | ||
| Help: "Error message for block, assistant reply for respond, and audit note for warn.", | ||
| // No Default: the dashboard would store it with the instance, so a | ||
| // warn would carry the block-phrased text as its audit note. | ||
| Key: "message", Label: "Message", Input: pluginapi.InputText, | ||
| Help: "Error message for block, assistant reply for respond, and audit note for warn. Left empty, block and respond fall back to " + DefaultMessage + " and warn records no note.", |
There was a problem hiding this comment.
Removing this field default makes dashboard-created configurations persist message: "". The configuration reader treats that as an intentional value rather than applying the action-specific fallback, so a matching block guardrail returns a blank error and a matching respond guardrail returns a blank assistant response. Normalize empty block/respond messages to the documented fallback before enforcement; this must be addressed before merging.
Knowledge Base Used: Plugin runtime and integration
Artifacts
- The executed script creates an isolated parent worktree and runs the same matching block/respond configuration with explicit empty messages on both revisions; it proves the compared runtime contract.
- Captured `go test` output from the parent revision shows block status 0 with an empty message and respond status 0 with empty response text; the prior behavior is blank.
- Captured `go test` output from the PR revision shows the same block status 0 empty message and respond status 0 empty response text; the defect remains.
There was a problem hiding this comment.
Fixed in bd78d44: a blank message now falls back to Request blocked by policy for block and respond (so a cleared field cannot produce an empty error or an empty assistant reply), while warn keeps no note. Added a table case covering "message": """ with on_match: block`.
|
@coderabbitai review |
|
@greptileai review |
Rate Limit Exceeded
|
|
@coderabbitai review |
Rate Limit Exceeded
|
|
@coderabbitai review |
|
Dashboard cosmetics and guardrail documentation gaps found in pre-release testing.
Dashboard
en/de(andplwhere the noun inflects): active scopes, effective model counts, hidden inactive keys, MCP servers needing attention, stream events. No more "1 active scopes" / "1 aktive Geltungsbereiche".input[type="password"](the Presidioapi_keyfield, any secret schema field) now gets the same styling as text/date/number inputs instead of the browser default.BLOCKED · STRING_REPLACE_MATCHno longer pushes the Response node out of the row.Guardrails (
string_replace)warnoutcome no longer borrows the block-phrased default message:messagefalls back toRequest blocked by policyonly forblockandrespond, and the schema field no longer carries that default, so an instance created in the dashboard does not store it. Warn records a note only when one is configured;block/respondbehaviour is unchanged.Docs
guardrails.mdx: stream-phase guardrails run on streamed requests only — a Presidiorestoresetup needs a response-phase instance to cover non-streaming requests, otherwise clients get raw<PERSON_1>placeholders.LOGGING_LOG_BODIESdefaults totrue, so auditrequest_body/response_bodykeep the values Presidio hides from the provider (only the revision body is anonymized).sk-[A-Za-z0-9_-]{20,}(current keys contain-) withstream_lookbehind: 256, plus a note that anything past the lookbehind reaches the client unmasked.PERSONspans can swallow an adjacent all-caps token, so a presidio step ahead ofstring_replacecan hide the words a later rule looks for.Testing
make test-dashboard(669 pass, including new i18n plural assertions),npm run check,make lint,go test ./....request_bodykeeps the original text whilerequest_revisionsholds the rewritten body, andsk-proj-…keys leak past a 64-character lookbehind but not at 256. Dashboard checked in a headless browser: secret field now 34px with the shared padding/border, chart badge truncated and Response node back in view.internal/serverTestVersionEndpointChecksOnFirstVisit/RechecksOnANewDayfail locally before and after this change: the visit cookie uses UTC while the test compares the local date, so they fail in CEST between midnight and 02:00. Untouched by this PR.