fix(audit): color workflow response node by status code#252
fix(audit): color workflow response node by status code#252SantiagoDePolonia merged 1 commit intomainfrom
Conversation
📝 WalkthroughWalkthroughThe PR adds HTTP status code visualization to workflow response nodes. It includes new CSS styling classes for warning and neutral states, updates the response node class computation logic to distinguish HTTP status families (3xx, 4xx, 5xx), and adds a sublabel element to display the exact status code. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Greptile SummaryThis PR enhances the Audit Logs workflow chart by coloring the Response node according to the same HTTP status buckets used by audit log entry badges, and by displaying the raw status code as a sublabel on the node. It adds two new helper methods ( Key changes:
Confidence Score: 5/5Safe to merge — purely additive UI enhancement with no changes to data flow, API contracts, or backend logic. The feature is self-contained: two new pure functions, one CSS block, and one template line. The logic is simple and mirrors the existing audit-badge convention. Four new tests explicitly validate all status-code buckets, and all pre-existing chart contract snapshot tests are updated consistently. No regressions in scope. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[workflowResponseNodeClass\nruntime] --> B{runtime exists?}
B -- No --> Z[return empty string]
B -- Yes --> C{statusCode is\nfinite number?}
C -- No --> Z
C -- Yes --> D{statusCode >= 500?}
D -- Yes --> E[workflow-node-error\n5xx Server Error]
D -- No --> F{statusCode >= 400?}
F -- Yes --> G[workflow-node-warning\n4xx Client Error]
F -- No --> H{statusCode >= 300?}
H -- Yes --> I[workflow-node-neutral\n3xx Redirect]
H -- No --> J{statusCode >= 200?}
J -- Yes --> K[workflow-node-success\n2xx Success]
J -- No --> Z
|
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/admin/dashboard/static/js/modules/workflows.test.js (1)
1908-1923:⚠️ Potential issue | 🟡 MinorAdd test cases for invalid status codes in response helper tests.
The helpers
workflowResponseNodeClassandworkflowResponseNodeSublabelalready validate against non-finite status codes usingNumber.isFinite(), but test coverage is missing for these edge cases. Add tests confirming that values like99,200.5, and600return empty string ('') andnullrespectively, alongside the existing coverage for valid 2xx, 3xx, 4xx, and 5xx codes.Also applies to: 1926-1955
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/admin/dashboard/static/js/modules/workflows.test.js` around lines 1908 - 1923, Add tests that exercise invalid/non-finite status codes for the response helpers: create runtime entries with status_code values 99, 200.5, and 600 and assert that module.workflowResponseNodeClass(...) returns '' and module.workflowResponseNodeSublabel(...) returns null for each; place these assertions alongside the existing valid-status assertions near the current workflowResponseNodeClass/workflowResponseNodeSublabel tests (the uncachedSuccess block) and repeat similarly where other response-helper tests exist (the following block referenced in the comment).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/admin/dashboard/static/js/modules/workflows.js`:
- Around line 1347-1360: The code accepts non-integer or out-of-range status
codes; update workflowResponseNodeClass and workflowResponseNodeSublabel to
first coerce/validate an integer HTTP status (e.g., use Math.floor or parseInt
then Number.isInteger) and only proceed if the integer is within the 100–599
range; otherwise return '' for class and null for sublabel. Ensure you reference
runtime.statusCode when validating so both methods reject values like 99, 200.5,
or 600 before computing classes or labels.
---
Outside diff comments:
In `@internal/admin/dashboard/static/js/modules/workflows.test.js`:
- Around line 1908-1923: Add tests that exercise invalid/non-finite status codes
for the response helpers: create runtime entries with status_code values 99,
200.5, and 600 and assert that module.workflowResponseNodeClass(...) returns ''
and module.workflowResponseNodeSublabel(...) returns null for each; place these
assertions alongside the existing valid-status assertions near the current
workflowResponseNodeClass/workflowResponseNodeSublabel tests (the
uncachedSuccess block) and repeat similarly where other response-helper tests
exist (the following block referenced in the comment).
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 830f612e-a466-4be9-accf-3fc26d42dfad
📒 Files selected for processing (4)
internal/admin/dashboard/static/css/dashboard.cssinternal/admin/dashboard/static/js/modules/workflows.jsinternal/admin/dashboard/static/js/modules/workflows.test.jsinternal/admin/dashboard/templates/workflow-chart.html
| workflowResponseNodeClass(runtime) { | ||
| if (!runtime) return ''; | ||
| return runtime.responseSuccess ? 'workflow-node-success' : ''; | ||
| const statusCode = runtime.statusCode; | ||
| if (!Number.isFinite(statusCode)) return ''; | ||
| if (statusCode >= 500) return 'workflow-node-error'; | ||
| if (statusCode >= 400) return 'workflow-node-warning'; | ||
| if (statusCode >= 300) return 'workflow-node-neutral'; | ||
| if (statusCode >= 200) return 'workflow-node-success'; | ||
| return ''; | ||
| }, | ||
|
|
||
| workflowResponseNodeSublabel(runtime) { | ||
| if (!runtime || !Number.isFinite(runtime.statusCode)) return null; | ||
| return String(runtime.statusCode); |
There was a problem hiding this comment.
Reject malformed finite status codes before coloring or displaying them.
Number.isFinite still accepts non-HTTP values like 99, 200.5, or 600; these can be rendered as real response statuses, and 600 would be colored as an error. Normalize to integer HTTP status codes before both class and sublabel computation.
Proposed fix
+ workflowResponseStatusCode(runtime) {
+ if (!runtime) return null;
+ const statusCode = Number(runtime.statusCode);
+ if (!Number.isInteger(statusCode) || statusCode < 100 || statusCode > 599) return null;
+ return statusCode;
+ },
+
workflowResponseNodeClass(runtime) {
- if (!runtime) return '';
- const statusCode = runtime.statusCode;
- if (!Number.isFinite(statusCode)) return '';
+ const statusCode = this.workflowResponseStatusCode(runtime);
+ if (statusCode === null) return '';
if (statusCode >= 500) return 'workflow-node-error';
if (statusCode >= 400) return 'workflow-node-warning';
if (statusCode >= 300) return 'workflow-node-neutral';
if (statusCode >= 200) return 'workflow-node-success';
return '';
},
workflowResponseNodeSublabel(runtime) {
- if (!runtime || !Number.isFinite(runtime.statusCode)) return null;
- return String(runtime.statusCode);
+ const statusCode = this.workflowResponseStatusCode(runtime);
+ return statusCode === null ? null : String(statusCode);
},🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@internal/admin/dashboard/static/js/modules/workflows.js` around lines 1347 -
1360, The code accepts non-integer or out-of-range status codes; update
workflowResponseNodeClass and workflowResponseNodeSublabel to first
coerce/validate an integer HTTP status (e.g., use Math.floor or parseInt then
Number.isInteger) and only proceed if the integer is within the 100–599 range;
otherwise return '' for class and null for sublabel. Ensure you reference
runtime.statusCode when validating so both methods reject values like 99, 200.5,
or 600 before computing classes or labels.
1 participant
Summary
Testing
Summary by CodeRabbit
New Features
Style
Tests