[Customer Entity] Add POST /security-report-analyses/search endpoint - #906
Conversation
|
Warning Review limit reached
More reviews will be available in 4 minutes and 40 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds a new ChangesSecurity Report Analysis Search Endpoint
Sequence Diagram(s)sequenceDiagram
participant Client
participant CaseHandler
participant snCaseService
participant ChoreoAPI as Choreo /cases/search
Client->>CaseHandler: POST /security-report-analyses/search (JSON body)
CaseHandler->>CaseHandler: decode SearchSecurityReportAnalysisRequest
CaseHandler->>snCaseService: SearchSecurityReportAnalysis(ctx, req)
snCaseService->>snCaseService: validate pagination, query, date ranges
snCaseService->>snCaseService: extract x-user-id-token from context
snCaseService->>snCaseService: map sortBy → SN field, merge deploymentId into deploymentIds
snCaseService->>ChoreoAPI: POST /cases/search (snCaseSearchPayload, caseTypes=security_report_analysis)
ChoreoAPI-->>snCaseService: snSecurityReportAnalysisResponse
snCaseService->>snCaseService: convert cases → []SecurityReportAnalysisView
snCaseService-->>CaseHandler: SearchSecurityReportAnalysisResponse
CaseHandler-->>Client: 200 JSON (SearchSecurityReportAnalysisResponse)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
entity-service/openapi.yaml (2)
1996-2003: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueClarify the dual deploymentId/deploymentIds design or add deduplication.
The schema allows both
deploymentId(singular) anddeploymentIds(array). If a client provides the same deployment ID in both fields, the ServiceNow implementation (lines 1339-1343 ofsn_case_service.go) will include it twice in the request payload. Whether this is problematic depends on ServiceNow's handling of duplicate filter values.Consider either:
- Documenting that
deploymentIdis a convenience alias and duplicates are acceptable, or- Adding deduplication logic in the ServiceNow implementation to prevent duplicate IDs.
🤖 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 `@entity-service/openapi.yaml` around lines 1996 - 2003, The OpenAPI schema allows both deploymentId (singular) and deploymentIds (array) fields, which can result in duplicate deployment IDs being sent to ServiceNow when a client provides the same ID in both fields. In the ServiceNow implementation in sn_case_service.go around lines 1339-1343 where the request payload is constructed, add deduplication logic to combine deploymentId and deploymentIds into a single deduplicated set before passing to ServiceNow, ensuring each unique deployment ID appears only once in the final request regardless of how the client provided the input.
2047-2049: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueConsider consistent workState representation across case-type search endpoints.
workStateis represented differently across similar endpoints:
SecurityReportAnalysisView(here): plainstringServiceRequestView(lines 1928-1930): structuredServiceRequestWorkStateRefwithidandlabelCaseSearchView(lines 1625-1629): enumstringIf these differences reflect the underlying ServiceNow data models, document the rationale in comments. Otherwise, consider aligning the representation for consistency.
🤖 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 `@entity-service/openapi.yaml` around lines 2047 - 2049, The workState property has inconsistent representations across similar endpoints: SecurityReportAnalysisView defines it as a plain nullable string, ServiceRequestView uses a structured ServiceRequestWorkStateRef object with id and label fields, and CaseSearchView defines it as an enum string. Either align all three endpoints to use the same workState representation (choose one consistent approach across SecurityReportAnalysisView, ServiceRequestView, and CaseSearchView), or if the differences intentionally reflect underlying ServiceNow data model variations, add explanatory comments above each workState definition documenting why they differ.
🤖 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.
Nitpick comments:
In `@entity-service/openapi.yaml`:
- Around line 1996-2003: The OpenAPI schema allows both deploymentId (singular)
and deploymentIds (array) fields, which can result in duplicate deployment IDs
being sent to ServiceNow when a client provides the same ID in both fields. In
the ServiceNow implementation in sn_case_service.go around lines 1339-1343 where
the request payload is constructed, add deduplication logic to combine
deploymentId and deploymentIds into a single deduplicated set before passing to
ServiceNow, ensuring each unique deployment ID appears only once in the final
request regardless of how the client provided the input.
- Around line 2047-2049: The workState property has inconsistent representations
across similar endpoints: SecurityReportAnalysisView defines it as a plain
nullable string, ServiceRequestView uses a structured ServiceRequestWorkStateRef
object with id and label fields, and CaseSearchView defines it as an enum
string. Either align all three endpoints to use the same workState
representation (choose one consistent approach across
SecurityReportAnalysisView, ServiceRequestView, and CaseSearchView), or if the
differences intentionally reflect underlying ServiceNow data model variations,
add explanatory comments above each workState definition documenting why they
differ.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 96326378-98d6-41ba-9132-cabc68e0bc3d
📒 Files selected for processing (7)
entity-service/internal/domain/entity.goentity-service/internal/handler/case_handler.goentity-service/internal/server/routes.goentity-service/internal/service/case_service.goentity-service/internal/service/interfaces.goentity-service/internal/service/sn_case_service.goentity-service/openapi.yaml
|
@coderabbitai review |
✅ Action performedReview finished.
|
3 participants
Summary
POST /security-report-analyses/searchendpoint backed exclusively by the ServiceNow data source (returns 503 for Postgres)POST /cases/searchAPI withcaseTypes: ["security_report_analysis"]projectIds,searchQuery,stateKeys, date ranges (closedStart/EndDate,startCreatedDate/endCreatedDate,startUpdatedDate/endUpdatedDate),deploymentId,deploymentIds,createdBy,createdByMesecurityReportAnalyses[]withid,internalId,number,createdOn,createdBy,title,description,state,workState(nullable string label),product,project,deployment,deployedProduct,assignedEngineer,parentCase,relatedCaseSummary by CodeRabbit