feat: add SSS client with Auth0 token caching#5058
Open
psrsingh wants to merge 1 commit into
Open
Conversation
Signed-off-by: psrsingh <psr.singh336@gmail.com>
WalkthroughThis pull request introduces a new Go package ChangesSanctions Screening Service (SSS) Go Client
Sequence DiagramsequenceDiagram
participant Client
participant Auth0Service as Auth0 OAuth Token
participant SSSService as SSS Organization Endpoint
Client->>Auth0Service: POST /oauth/token (client credentials)
Auth0Service-->>Client: access_token, expires_in
Client->>SSSService: GET /organizations/status?organization_id=X<br/>(Authorization: Bearer token)
SSSService-->>Client: 200 ScreeningResult (status, entityID, source, screened_at)
Note over Client: or 400/401/503 mapped to<br/>BadRequestError/AuthError/RetryableError
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 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 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. 🔧 golangci-lint (2.12.2)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies" Comment |
![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 `@cla-backend-go/sss/client.go`:
- Around line 208-210: The parsed Retry-After timestamp may be in the past
causing time.Until(parsedTime) to return a negative duration; update the block
that uses http.ParseTime (the parsedTime handling in sss/client.go) to clamp the
returned duration to a non-negative value—compute d := time.Until(parsedTime)
and return time.Duration(0) if d < 0 else return d—so callers never receive
negative RetryAfter durations.
🪄 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: CHILL
Plan: Pro
Run ID: aaca0b5d-8df6-44b3-8128-17f2342fda31
📒 Files selected for processing (5)
cla-backend-go/sss/auth.gocla-backend-go/sss/client.gocla-backend-go/sss/client_test.gocla-backend-go/sss/errors.gocla-backend-go/sss/types.go
Comment on lines
+208
to
+210
| if parsedTime, err := http.ParseTime(value); err == nil { | ||
| return time.Until(parsedTime) | ||
| } |
There was a problem hiding this comment.
Clamp parsed Retry-After to non-negative duration.
http.ParseTime can yield a past timestamp, returning a negative duration. Exposing negative RetryAfter can cause incorrect retry scheduling.
💡 Proposed fix
if parsedTime, err := http.ParseTime(value); err == nil {
- return time.Until(parsedTime)
+ d := time.Until(parsedTime)
+ if d < 0 {
+ return 0
+ }
+ return d
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if parsedTime, err := http.ParseTime(value); err == nil { | |
| return time.Until(parsedTime) | |
| } | |
| if parsedTime, err := http.ParseTime(value); err == nil { | |
| d := time.Until(parsedTime) | |
| if d < 0 { | |
| return 0 | |
| } | |
| return d | |
| } |
🤖 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 `@cla-backend-go/sss/client.go` around lines 208 - 210, The parsed Retry-After
timestamp may be in the past causing time.Until(parsedTime) to return a negative
duration; update the block that uses http.ParseTime (the parsedTime handling in
sss/client.go) to clamp the returned duration to a non-negative value—compute d
:= time.Until(parsedTime) and return time.Duration(0) if d < 0 else return d—so
callers never receive negative RetryAfter durations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a reusable Sanctions Screening Service (SSS) client package for EasyCLA.
Features
Auth0 M2M authentication using client credentials flow
in-memory token caching with refresh-before-expiry behavior
reusable HTTP client with configurable timeout
typed response models for SSS organization screening
typed error handling for:
context-aware requests
thread-safe token reuse using mutex protection
Tests
Added mocked HTTP tests using
httptestfor:Validation
Notes
The referenced API documentation files were not present in the repository, so the implementation follows the issue specification and currently uses a provisional
organization_idquery parameter pending confirmation.