chore: import integration tests from stack repository#44
Conversation
WalkthroughThe pull request primarily updates import paths for various packages from version 1 to version 2 of the Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant V as V1 (SDK)
participant H as Hooks Manager
participant C as ClientCredentialsHook
participant A as HTTPClient
participant S as Server
U->>V: Invoke API method (e.g., GetOIDCWellKnowns)
V->>H: Execute BeforeRequest hooks
H->>C: Initiate token validation
alt Token missing/expired
C->>A: Perform token request
A-->>C: Return token response
end
C->>H: Update request with valid token
H->>V: Return modified request
V->>A: Send API request
A-->>V: Receive API response
V->>H: Execute AfterSuccess hooks
V-->>U: Return API response
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
gfyrag
force-pushed
the
chore/import-integrations-tests-from-stack-repository
branch
from
c165e72 to
7f8980f
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🔭 Outside diff range comments (1)
pkg/client/internal/utils/security.go (1)
150-275: 🛠️ Refactor suggestionRecommend returning an error instead of panicking.
The code within
parseSecuritySchemeValuecallspanic("not supported")for unsupported security types. Panics can be disruptive in library code. Instead, consider returning an error to the caller, preserving system stability and enabling graceful fallback:- panic("not supported") + return // e.g., log the unsupported scheme or return an errorThis change would make the code more robust and production-friendly.
🧹 Nitpick comments (53)
pkg/client/.gitignore (1)
1-2: Minimal .gitignore File AddedThe new
.gitignorefile only contains a comment line. Given the scope of this integration and the potential for generated files or intermediary artifacts in the client directory, please consider adding specific ignore patterns (e.g., build artifacts, temporary files, IDE-specific files) to keep the repository clean.pkg/client/types/date.go (3)
53-68: Be cautious withMustfunctions in production code.While the comment appropriately warns against using these panic-inducing functions in production, consider adding tests that verify their panic behavior to ensure they work as expected.
78-86: Consider handling empty strings explicitly in UnmarshalJSON.The function currently doesn't check if the string is empty after trimming quotes. While
time.Parsewill return an error for empty strings, it might be clearer to handle this edge case explicitly.func (d *Date) UnmarshalJSON(data []byte) error { var err error str := string(data) str = strings.Trim(str, `"`) + if str == "" { + return fmt.Errorf("empty date string") + } d.Time, err = time.Parse("2006-01-02", str) return err }
5-90: Consider extracting the date format string as a constant.The date format string "2006-01-02" is repeated multiple times throughout the file. It would improve maintainability to define it as a package-level constant to ensure consistency.
package types import ( "encoding/json" "fmt" "strings" "time" ) + // DateFormat is the standard date format used for JSON marshaling/unmarshaling + const DateFormat = "2006-01-02" // Date is a wrapper around time.Time that allows for JSON marshaling a date string formatted as "2006-01-02".Then update each occurrence of the hardcoded format string to use this constant.
pkg/client/docs/sdks/formance/README.md (1)
1-8: Documentation needs completion.This README file appears to be a skeleton or placeholder for SDK documentation. While the basic structure is in place (title, overview, available operations), there's no actual content to guide users on how to work with the SDK.
Consider completing this documentation with:
- A brief description of the SDK's purpose in the Overview section
- A list of all available operations with descriptions and basic usage examples
- Installation instructions
- Basic usage examples or getting started guide
pkg/client/types/bigint.go (1)
1-21: Function contains appropriate warning about panic behavior.The implementation of
MustNewBigIntFromStringis clean and properly documented, with an explicit warning about avoiding use in production code due to its panic behavior.For production environments, consider also providing a non-panicking alternative:
// NewBigIntFromString attempts to parse a string as a base-10 big.Int // and returns an error if parsing fails instead of panicking. func NewBigIntFromString(s string) (*big.Int, error) { i, ok := new(big.Int).SetString(s, 10) if !ok { return nil, fmt.Errorf("failed to parse string as big.Int: %s", s) } return i, nil }pkg/client/types/decimal.go (1)
1-20: Function contains appropriate warning about panic behavior.The implementation of
MustNewDecimalFromStringis clean and properly documented, with an explicit warning about avoiding use in production code due to its panic behavior.For production environments, consider also providing a non-panicking alternative:
// NewDecimalFromString attempts to parse a string as a decimal.Big // and returns an error if parsing fails instead of panicking. func NewDecimalFromString(s string) (*decimal.Big, error) { d, ok := new(decimal.Big).SetString(s) if !ok { return nil, fmt.Errorf("failed to parse string as decimal.Big: %s", s) } return d, nil }pkg/client/USAGE.md (1)
1-31: Good example, but could be enhanced to be more informativeThis example clearly demonstrates the basic usage of the client SDK, which is helpful. However, consider enhancing it with:
- A comment explaining that users need to replace the empty security credentials.
- A simple example of how to process the response.
- An additional explanation of what the GetOIDCWellKnowns method does.
<!-- Start SDK Example Usage [usage] --> ```go package main import ( "context" "github.com/formancehq/auth/pkg/client" "github.com/formancehq/auth/pkg/client/models/components" "log" ) func main() { s := client.New( client.WithSecurity(components.Security{ + // Replace with your actual credentials ClientID: "", ClientSecret: "", }), ) ctx := context.Background() res, err := s.Auth.V1.GetOIDCWellKnowns(ctx) if err != nil { log.Fatal(err) } if res != nil { - // handle response + // Process the OIDC well-known configuration + log.Printf("Issuer: %s", res.OIDCJWKS.Issuer) + // Access other fields as needed } }
+<!-- This example shows how to fetch OIDC well-known configuration which provides
information about the OpenID Connect provider's endpoints and capabilities. --></blockquote></details> <details> <summary>pkg/client/CONTRIBUTING.md (1)</summary><blockquote> `14-14`: **Fix unordered list indentation** The indentation for this bullet point is inconsistent with the rest of the list. Markdown linting suggests using 2 spaces for indentation instead of 4. ```diff - - For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installed + - For example can be collected using the `npx envinfo` command from your terminal if you have Node.js installed🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
14-14: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
pkg/client/README.md (3)
299-308: Custom HTTP Client Section – Style Improvement
The sentence:“The requirements for the HTTP client are very simple. It must match this interface:”
could benefit from rephrasing to avoid the over-used intensifier “very”. For example, consider:
“The HTTP client must satisfy a straightforward interface:”🧰 Tools
🪛 LanguageTool
[style] ~302-~302: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...he requirements for the HTTP client are very simple. It must match this interface: ```go t...(EN_WEAK_ADJECTIVE)
312-316: Custom HTTP Client Timeout Example – Hyphenation
In the example, “a client with a 30 second timeout” should be refined to “a client with a 30‑second timeout” (using a hyphen in the compound adjective).Suggested diff:
- // a client with a 30 second timeout + // a client with a 30-second timeout
388-393: Contributions Section – Style Refinements
The phrase “Feel free to open a PR or an issue…” appears in the contributions section. Consider a more formal alternative such as “You are encouraged to submit a pull request or open an issue…” Additionally, add a comma before “and we’ll do our best…” to improve sentence clarity.Suggested diff:
- We look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of concept and we'll do our best to include it in a future release. + We look forward to your feedback. You are encouraged to open a PR or an issue with a proof of concept, and we'll do our best to include it in a future release.🧰 Tools
🪛 LanguageTool
[style] ~391-~391: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~391-~391: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...(COMMA_COMPOUND_SENTENCE)
pkg/client/internal/utils/json.go (3)
21-115: Review ofMarshalJSONfunction (lines 21-115)
- This function provides a highly customized JSON marshaling solution via reflection and tag parsing. Overall, it appears structurally correct, but:
- Performance caution: Reflection-heavy logic can be harder to maintain and slower at runtime. If performance becomes critical, consider caching reflective lookups in a map keyed by type.
unsafeusage: Transitioning tounsafe.Pointer()can be risky. If possible, investigate whether high-level reflection equivalents exist to avoid potential memory or alignment pitfalls.- Map iteration: In the block handling
additionalProperties(lines 69-88), the iteration logic is correct, but be mindful of potential key collisions if a struct also has named fields that overlap with these map keys. Confirm that the use case does not require any special collision handling.
351-389: Review ofhandleDefaultConstValuefunction (lines 351-389)
- Const and default handling: This function merges logic for default and const values. It’s a compact approach, but be cautious about expansions—this single function already deals with multiple custom tags (time, big.Int, decimal, etc.).
- Implicit string conversion: For unrecognized or struct-like types, the function resorts to a raw string embedding. This is correct for current usage, but quickly verifying more exotic types or nested defaults is recommended if the code evolves.
621-670: Review of helper pointer & type-checking functions (lines 621-670)
- Recursive dereferencing: Both
dereferencePointersanddereferenceTypePointerrecursively strip pointer layers. This works but could cause unexpected behavior if infinite pointer recursion occurs in a malformed structure. Consider adding a recursion limit or check forval.IsValid()/val.CanAddr()as a safety measure.isModelType: The definition of “model type” is purelystructthat isn’t one of the recognized complex types. This is a good approach, but be ready to revisit if your domain objects become more sophisticated or incorporate embedded struct pointers.pkg/client/docs/models/components/serverinfo.md (1)
1-8: ServerInfo Documentation is ClearThe documentation for the
ServerInfocomponent is concise and appropriately documents theVersionfield. If possible, consider elaborating on the field description in the future to provide context beyond "N/A".pkg/client/docs/models/components/listclientsresponse.md (1)
1-8: Review Markdown Link Syntax in ListClientsResponseThe documentation neatly outlines the
ListClientsResponsemodel. However, note that theDatafield currently uses the syntax[][components.Client](../../models/components/client.md), which appears to include an extra set of square brackets. Consider verifying and correcting the markdown link so it is consistent with the other files (e.g.,[components.Client](../../models/components/client.md)) if that was the intended format.pkg/client/docs/models/components/user.md (1)
1-10: Enhance Type Formatting Consistency in User Documentation
The documentation is comprehensive and includes useful examples. One minor note: the type declaration for fields (e.g.,**string*) may have a markdown formatting inconsistency. Consider revising it to either*string*or**string**for improved clarity and consistency.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
10-10: Bare URL used
null(MD034, no-bare-urls)
pkg/client/docs/models/components/clientsecret.md (1)
1-11: Well-Structured ClientSecret Documentation with Minor Formatting Suggestion
The table clearly details each field of theClientSecretmodel. For clarity and consistency, consider wrapping the typemap[string]*any*in an inline code block (e.g.,`map[string]*any`) so that it stands out as a type declaration.pkg/client/docs/models/components/listusersresponse.md (1)
1-8: Review of Markdown Link Syntax
The documentation forListUsersResponseis well-structured; however, the link in the "Type" column for theDatafield appears inconsistent. The syntax[][components.User](../../models/components/user.md)seems off compared to similar files. Consider revising it to a format such as[*components.User](../../models/components/user.md)for consistency.pkg/client/docs/models/components/secret.md (1)
1-12: Well-Structured Secret Component Documentation
TheSecretdocumentation is cleanly structured with clearly defined fields. For improved clarity, consider providing more detailed descriptions in the "Description" column if additional context becomes available.pkg/client/docs/models/operations/createsecretrequest.md (1)
1-9: Operation Documentation for CreateSecretRequest is Consistent
This file outlines the CreateSecretRequest model used in operations with a clear table includingClientIDand the nestedCreateSecretRequestfield. As a nitpick, consider reviewing the naming redundancy of theCreateSecretRequestfield to prevent potential confusion with the component model of the same name.pkg/client/docs/models/operations/getserverinforesponse.md (1)
1-9: Documentation looks good, but field descriptions could be enhanced.The structure of this documentation file aligns well with the expected markdown format for API response documentation. However, the
HTTPMetafield has a description of "N/A", which could be improved to provide more context to developers about its purpose and usage.Consider enhancing the field descriptions to provide more detailed information about:
- What information
HTTPMetacontains (e.g., status codes, headers)- More specific details about what kind of server information is contained in the
ServerInfofieldpkg/client/docs/models/operations/createclientresponse.md (1)
1-9: Documentation structure is good, but field description for HTTPMeta is missing.The markdown structure follows the expected format for API response documentation. The description for
CreateClientResponse("Client created") provides some context, but theHTTPMetafield lacks a proper description (marked as "N/A").Consider adding a clear description for the
HTTPMetafield to explain what HTTP metadata is included and how it's typically used by API consumers.pkg/client/docs/models/operations/updateclientresponse.md (1)
1-9: Note naming conflict between model and fieldThere appears to be a naming conflict in this documentation. Both the model itself and one of its fields are named
UpdateClientResponse, which could lead to confusion for API consumers.Consider renaming the field to something more descriptive like
ClientorUpdatedClientto better distinguish between the container model and its content.pkg/client/docs/models/operations/readclientresponse.md (1)
1-9: Note naming conflict between model and fieldSimilar to the UpdateClientResponse documentation, there's a naming conflict where both the model and one of its fields share the same name
ReadClientResponse.Consider renaming the field to something more descriptive like
ClientorRetrievedClientto better distinguish between the container model and its content.pkg/client/docs/models/operations/listclientsresponse.md (1)
4-9: Consider improving field descriptionsWhile the structure is correct, the documentation would be more helpful with detailed descriptions instead of "N/A" for the
HTTPMetafield. Adding information about what the HTTP metadata contains would make this documentation more useful for developers.pkg/client/docs/models/components/createclientrequest.md (1)
4-15: Add meaningful field descriptionsAll fields have "N/A" as their description, which reduces the documentation's usefulness. Consider adding detailed descriptions for each field to help developers understand:
- What
Publicmeans in the context of a client- Expected format and purpose of
RedirectUris- Purpose of the
Trustedflag- Format requirements for
PostLogoutRedirectUris- What types of data should be included in
Metadata- What
Scopesare available and how they affect client permissionsProper documentation will improve developer experience and reduce potential misuse.
pkg/client/docs/models/components/security.md (1)
1-10: Documentation lacks detailed descriptions and examplesWhile the table structure is clear, the documentation would be more helpful with:
- Specific descriptions for each field instead of "N/A"
- Examples for each security field to guide implementation
For instance:
ClientID: A description of what this represents in the OAuth flowClientSecret: Information about secure handling of this sensitive valueTokenURL: Expected format or typical endpoint structureConsider enhancing this documentation with more detailed descriptions and examples to improve developer experience.
pkg/client/docs/sdks/v1/README.md (1)
1-593: Consider fixing markdown linting issues.The markdown file has several linting issues flagged by static analysis, including:
- Hard tabs instead of spaces in code blocks
- Missing blank lines around tables
- Heading increment issues
These are minor formatting issues that don't affect functionality but might improve readability.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3(MD001, heading-increment)
28-28: Hard tabs
Column: 1(MD010, no-hard-tabs)
29-29: Hard tabs
Column: 1(MD010, no-hard-tabs)
30-30: Hard tabs
Column: 1(MD010, no-hard-tabs)
31-31: Hard tabs
Column: 1(MD010, no-hard-tabs)
64-64: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
78-78: Hard tabs
Column: 1(MD010, no-hard-tabs)
79-79: Hard tabs
Column: 1(MD010, no-hard-tabs)
80-80: Hard tabs
Column: 1(MD010, no-hard-tabs)
81-81: Hard tabs
Column: 1(MD010, no-hard-tabs)
114-114: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
128-128: Hard tabs
Column: 1(MD010, no-hard-tabs)
129-129: Hard tabs
Column: 1(MD010, no-hard-tabs)
130-130: Hard tabs
Column: 1(MD010, no-hard-tabs)
131-131: Hard tabs
Column: 1(MD010, no-hard-tabs)
164-164: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
178-178: Hard tabs
Column: 1(MD010, no-hard-tabs)
179-179: Hard tabs
Column: 1(MD010, no-hard-tabs)
180-180: Hard tabs
Column: 1(MD010, no-hard-tabs)
181-181: Hard tabs
Column: 1(MD010, no-hard-tabs)
215-215: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
229-229: Hard tabs
Column: 1(MD010, no-hard-tabs)
230-230: Hard tabs
Column: 1(MD010, no-hard-tabs)
231-231: Hard tabs
Column: 1(MD010, no-hard-tabs)
232-232: Hard tabs
Column: 1(MD010, no-hard-tabs)
233-233: Hard tabs
Column: 1(MD010, no-hard-tabs)
269-269: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
283-283: Hard tabs
Column: 1(MD010, no-hard-tabs)
284-284: Hard tabs
Column: 1(MD010, no-hard-tabs)
285-285: Hard tabs
Column: 1(MD010, no-hard-tabs)
286-286: Hard tabs
Column: 1(MD010, no-hard-tabs)
287-287: Hard tabs
Column: 1(MD010, no-hard-tabs)
323-323: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
337-337: Hard tabs
Column: 1(MD010, no-hard-tabs)
338-338: Hard tabs
Column: 1(MD010, no-hard-tabs)
339-339: Hard tabs
Column: 1(MD010, no-hard-tabs)
340-340: Hard tabs
Column: 1(MD010, no-hard-tabs)
341-341: Hard tabs
Column: 1(MD010, no-hard-tabs)
377-377: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
391-391: Hard tabs
Column: 1(MD010, no-hard-tabs)
392-392: Hard tabs
Column: 1(MD010, no-hard-tabs)
393-393: Hard tabs
Column: 1(MD010, no-hard-tabs)
394-394: Hard tabs
Column: 1(MD010, no-hard-tabs)
395-395: Hard tabs
Column: 1(MD010, no-hard-tabs)
431-431: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
445-445: Hard tabs
Column: 1(MD010, no-hard-tabs)
446-446: Hard tabs
Column: 1(MD010, no-hard-tabs)
447-447: Hard tabs
Column: 1(MD010, no-hard-tabs)
448-448: Hard tabs
Column: 1(MD010, no-hard-tabs)
449-449: Hard tabs
Column: 1(MD010, no-hard-tabs)
486-486: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
500-500: Hard tabs
Column: 1(MD010, no-hard-tabs)
501-501: Hard tabs
Column: 1(MD010, no-hard-tabs)
502-502: Hard tabs
Column: 1(MD010, no-hard-tabs)
503-503: Hard tabs
Column: 1(MD010, no-hard-tabs)
536-536: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
550-550: Hard tabs
Column: 1(MD010, no-hard-tabs)
551-551: Hard tabs
Column: 1(MD010, no-hard-tabs)
552-552: Hard tabs
Column: 1(MD010, no-hard-tabs)
553-553: Hard tabs
Column: 1(MD010, no-hard-tabs)
554-554: Hard tabs
Column: 1(MD010, no-hard-tabs)
590-590: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
pkg/client/docs/models/operations/option.md (2)
11-20: Heading level inconsistency.The heading for
WithTemplatedServerURLuses##while the other options use###, creating inconsistency in the documentation hierarchy.-## WithTemplatedServerURL +### WithTemplatedServerURL
1-37: Documentation could be enhanced with more details.While the documentation clearly explains each option with good examples, it would be more helpful to include:
- Default values or behavior when options aren't specified
- Whether these options can be combined
- Any limitations or considerations when using these options
pkg/client/docs/models/components/client.md (1)
8-17: Type formatting appears inconsistent with Go conventions.The type formatting in the documentation doesn't match standard Go type notation:
**bool*instead of*bool[]*string*instead of[]*stringThis might confuse developers familiar with Go. Consider revising the type formatting to match Go conventions.
pkg/client/models/operations/readclient.go (2)
9-19: Struct and getter method look solid.The
ReadClientRequeststruct and theGetClientID()method exhibit clear design. Returning an empty string fornilchecks is a valid approach for resilience, though it may be worth verifying that upstream code gracefully handles empty client IDs.
21-25: Consider renaming the field to avoid name collisions.Having a struct named
ReadClientResponsewithin a field also calledReadClientResponsecan be confusing. A minor rename might improve clarity:type ReadClientResponse struct { HTTPMeta components.HTTPMetadata `json:"-"` // Retrieved client - ReadClientResponse *components.ReadClientResponse + ClientData *components.ReadClientResponse }pkg/client/internal/utils/headers.go (1)
55-124: Consider modularizingserializeHeader.
serializeHeaderis quite large, handling multiple data kinds (struct, map, slice, etc.). Consider splitting it into smaller helpers for improved readability and easier testing:pkg/client/internal/utils/pathparams.go (3)
36-36: Handle the case of no matching path parameters.There's a TODO comment about possibly handling the situation where none of the path parameters match the placeholders in the URL. Consider implementing a fallback or logging to avoid incomplete URLs.
Would you like help prototyping a solution to address this case?
80-81: Support other serialization styles.A TODO annotation indicates more serialization styles may be needed. Consider extending the implementation to handle additional styles (e.g., matrix, label) if required by the specification.
40-92: Reflect-based approach may impact performance.This reflection-heavy population logic is powerful but can be slower than a hand-coded alternative. If performance for path parameter generation becomes critical, consider optimized routes or caching reflection results.
pkg/client/internal/utils/queryparams.go (1)
250-255: Consider moving type definition earlier.The
paramTagstruct is defined at the end of the file but used much earlier. For better readability, consider moving the type definition before its first usage.Also applies to: 257-259
pkg/client/internal/utils/utils.go (2)
48-57: Potential issue with parameter replacement.The
ReplaceParametersfunction will replace parameters not found in the map with empty strings. Consider handling missing parameters differently.func ReplaceParameters(stringWithParams string, params map[string]string) string { if len(params) == 0 { return stringWithParams } return paramRegex.ReplaceAllStringFunc(stringWithParams, func(match string) string { match = match[1 : len(match)-1] - return params[match] + value, exists := params[match] + if !exists { + return match + } + return value }) }
223-230: Remove duplicatecontainsfunction.The
containsfunction duplicates the functionality of theContainsfunction defined earlier. Use one consistent function throughout the codebase.-func contains(arr []string, str string) bool { - for _, a := range arr { - if a == str { - return true - } - } - return false -}And update all references to
containsto useContainsinstead.cmd/serve.go (1)
37-45: Consider aligning constant naming convention.
The new exported flags look good. However, for consistent CamelCase usage, you might renameBaseUrlFlagtoBaseURLFlagto match Go convention for acronyms like “URL.”-const ( - BaseUrlFlag = "base-url" +const ( + BaseURLFlag = "base-url"pkg/client/formance.go (2)
26-42: Use generics to simplify pointer helper functions.
The pointer helper functions (String,Bool,Int, etc.) are standard approaches. In Go ≥1.18, you can use generics to avoid repetitive boilerplate.// Example generic approach func Ptr[T any](v T) *T { return &v }
140-171: Revisit the 60s default HTTP timeout.
Currently, you default to a 60-second timeout when the user does not provide one. Ensure that this aligns with desired performance targets. You might expose this value or reduce it for sensitive production environments to fail fast on unresponsive endpoints.pkg/client/internal/utils/requestbody.go (4)
41-83: Consider potential reflection overhead
Reflection-based field inspection can be slow for large or frequently accessed structs. You may consider caching reflection metadata or using a more direct approach for performance-sensitive paths.
89-97: Clarify behavior for null requests on non-JSON content
The TODO suggests uncertainty about handling null or empty content when the media type isn’t JSON. Finalize this logic to avoid unintended behavior.
211-250: Validate file parameters more robustly
Check that file fields (e.g., name, filename, content) are valid and non-empty to prevent broken or malicious uploads.
288-289: Add support for more form data styles
A TODO indicates partial coverage of form styles. Implementing additional styles (spaceDelimited, pipeDelimited, etc.) can extend compatibility with various OpenAPI specs.Do you want me to open an issue to track these enhancements?
pkg/client/internal/hooks/clientcredentials.go (1)
63-92: Regulate in-memory client credentials
Storing client credentials in memory is fine for short sessions, but consider adding a rotation or expiration mechanism to limit potential exposure.pkg/client/internal/hooks/hooks.go (3)
66-71: Consider standardized field naming
The arrays (sdkInitHooks,beforeRequestHook, etc.) could be pluralized for clarity, e.g.beforeRequestHooks.
73-92: Make default credentials hook optional
New()unconditionally registers the client credentials hook. Expose a way to skip it if OAuth2 is not needed.
143-152: Reassess FailEarly behavior
Stopping further hook execution helps in some use cases, but can hamper partial processing in others. Confirm this design matches all workflows.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (7)
go.modis excluded by!**/*.modgo.sumis excluded by!**/*.sum,!**/*.sumopenapi.yamlis excluded by!**/*.yamlpkg/client/.speakeasy/gen.lockis excluded by!**/*.lock,!**/*.lockpkg/client/.speakeasy/gen.yamlis excluded by!**/*.yamlpkg/client/go.modis excluded by!**/*.modpkg/client/go.sumis excluded by!**/*.sum,!**/*.sum
📒 Files selected for processing (107)
cmd/root.go(1 hunks)cmd/serve.go(6 hunks)pkg/api/authorization/accesstoken_test.go(1 hunks)pkg/api/authorization/main_test.go(1 hunks)pkg/api/clients.go(1 hunks)pkg/api/clients_test.go(1 hunks)pkg/api/main_test.go(1 hunks)pkg/api/module.go(1 hunks)pkg/api/users_test.go(1 hunks)pkg/api/util.go(1 hunks)pkg/api/util_test.go(1 hunks)pkg/client/.gitattributes(1 hunks)pkg/client/.gitignore(1 hunks)pkg/client/CONTRIBUTING.md(1 hunks)pkg/client/README.md(1 hunks)pkg/client/USAGE.md(1 hunks)pkg/client/auth.go(1 hunks)pkg/client/docs/models/components/client.md(1 hunks)pkg/client/docs/models/components/clientsecret.md(1 hunks)pkg/client/docs/models/components/createclientrequest.md(1 hunks)pkg/client/docs/models/components/createclientresponse.md(1 hunks)pkg/client/docs/models/components/createsecretrequest.md(1 hunks)pkg/client/docs/models/components/createsecretresponse.md(1 hunks)pkg/client/docs/models/components/httpmetadata.md(1 hunks)pkg/client/docs/models/components/listclientsresponse.md(1 hunks)pkg/client/docs/models/components/listusersresponse.md(1 hunks)pkg/client/docs/models/components/readclientresponse.md(1 hunks)pkg/client/docs/models/components/readuserresponse.md(1 hunks)pkg/client/docs/models/components/secret.md(1 hunks)pkg/client/docs/models/components/security.md(1 hunks)pkg/client/docs/models/components/serverinfo.md(1 hunks)pkg/client/docs/models/components/updateclientrequest.md(1 hunks)pkg/client/docs/models/components/updateclientresponse.md(1 hunks)pkg/client/docs/models/components/user.md(1 hunks)pkg/client/docs/models/operations/createclientresponse.md(1 hunks)pkg/client/docs/models/operations/createsecretrequest.md(1 hunks)pkg/client/docs/models/operations/createsecretresponse.md(1 hunks)pkg/client/docs/models/operations/deleteclientrequest.md(1 hunks)pkg/client/docs/models/operations/deleteclientresponse.md(1 hunks)pkg/client/docs/models/operations/deletesecretrequest.md(1 hunks)pkg/client/docs/models/operations/deletesecretresponse.md(1 hunks)pkg/client/docs/models/operations/getoidcwellknownsresponse.md(1 hunks)pkg/client/docs/models/operations/getserverinforesponse.md(1 hunks)pkg/client/docs/models/operations/listclientsresponse.md(1 hunks)pkg/client/docs/models/operations/listusersresponse.md(1 hunks)pkg/client/docs/models/operations/option.md(1 hunks)pkg/client/docs/models/operations/readclientrequest.md(1 hunks)pkg/client/docs/models/operations/readclientresponse.md(1 hunks)pkg/client/docs/models/operations/readuserrequest.md(1 hunks)pkg/client/docs/models/operations/readuserresponse.md(1 hunks)pkg/client/docs/models/operations/updateclientrequest.md(1 hunks)pkg/client/docs/models/operations/updateclientresponse.md(1 hunks)pkg/client/docs/sdks/formance/README.md(1 hunks)pkg/client/docs/sdks/v1/README.md(1 hunks)pkg/client/formance.go(1 hunks)pkg/client/internal/hooks/clientcredentials.go(1 hunks)pkg/client/internal/hooks/hooks.go(1 hunks)pkg/client/internal/hooks/registration.go(1 hunks)pkg/client/internal/utils/contenttype.go(1 hunks)pkg/client/internal/utils/form.go(1 hunks)pkg/client/internal/utils/headers.go(1 hunks)pkg/client/internal/utils/json.go(1 hunks)pkg/client/internal/utils/pathparams.go(1 hunks)pkg/client/internal/utils/queryparams.go(1 hunks)pkg/client/internal/utils/requestbody.go(1 hunks)pkg/client/internal/utils/retries.go(1 hunks)pkg/client/internal/utils/security.go(1 hunks)pkg/client/internal/utils/utils.go(1 hunks)pkg/client/models/components/client.go(1 hunks)pkg/client/models/components/clientsecret.go(1 hunks)pkg/client/models/components/createclientrequest.go(1 hunks)pkg/client/models/components/createclientresponse.go(1 hunks)pkg/client/models/components/createsecretrequest.go(1 hunks)pkg/client/models/components/createsecretresponse.go(1 hunks)pkg/client/models/components/httpmetadata.go(1 hunks)pkg/client/models/components/listclientsresponse.go(1 hunks)pkg/client/models/components/listusersresponse.go(1 hunks)pkg/client/models/components/readclientresponse.go(1 hunks)pkg/client/models/components/readuserresponse.go(1 hunks)pkg/client/models/components/secret.go(1 hunks)pkg/client/models/components/security.go(1 hunks)pkg/client/models/components/serverinfo.go(1 hunks)pkg/client/models/components/updateclientrequest.go(1 hunks)pkg/client/models/components/updateclientresponse.go(1 hunks)pkg/client/models/components/user.go(1 hunks)pkg/client/models/operations/createclient.go(1 hunks)pkg/client/models/operations/createsecret.go(1 hunks)pkg/client/models/operations/deleteclient.go(1 hunks)pkg/client/models/operations/deletesecret.go(1 hunks)pkg/client/models/operations/getoidcwellknowns.go(1 hunks)pkg/client/models/operations/getserverinfo.go(1 hunks)pkg/client/models/operations/listclients.go(1 hunks)pkg/client/models/operations/listusers.go(1 hunks)pkg/client/models/operations/options.go(1 hunks)pkg/client/models/operations/readclient.go(1 hunks)pkg/client/models/operations/readuser.go(1 hunks)pkg/client/models/operations/updateclient.go(1 hunks)pkg/client/models/sdkerrors/sdkerror.go(1 hunks)pkg/client/retry/config.go(1 hunks)pkg/client/types/bigint.go(1 hunks)pkg/client/types/date.go(1 hunks)pkg/client/types/datetime.go(1 hunks)pkg/client/types/decimal.go(1 hunks)pkg/client/types/pointers.go(1 hunks)pkg/client/v1.go(1 hunks)pkg/oidc/main_test.go(1 hunks)pkg/oidc/oidc_test.go(1 hunks)
⛔ Files not processed due to max files limit (8)
- pkg/oidc/storage.go
- pkg/storage/sqlstorage/database.go
- pkg/storage/sqlstorage/module.go
- pkg/testserver/helpers.go
- pkg/testserver/server.go
- test/e2e/client_credentials_test.go
- test/e2e/jwt_bearer_test.go
- test/e2e/suite_test.go
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
pkg/client/docs/models/components/user.md
10-10: Bare URL used
null
(MD034, no-bare-urls)
pkg/client/CONTRIBUTING.md
14-14: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
pkg/client/docs/sdks/v1/README.md
4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
28-28: Hard tabs
Column: 1
(MD010, no-hard-tabs)
29-29: Hard tabs
Column: 1
(MD010, no-hard-tabs)
30-30: Hard tabs
Column: 1
(MD010, no-hard-tabs)
31-31: Hard tabs
Column: 1
(MD010, no-hard-tabs)
64-64: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
78-78: Hard tabs
Column: 1
(MD010, no-hard-tabs)
79-79: Hard tabs
Column: 1
(MD010, no-hard-tabs)
80-80: Hard tabs
Column: 1
(MD010, no-hard-tabs)
81-81: Hard tabs
Column: 1
(MD010, no-hard-tabs)
114-114: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
128-128: Hard tabs
Column: 1
(MD010, no-hard-tabs)
129-129: Hard tabs
Column: 1
(MD010, no-hard-tabs)
130-130: Hard tabs
Column: 1
(MD010, no-hard-tabs)
131-131: Hard tabs
Column: 1
(MD010, no-hard-tabs)
164-164: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
178-178: Hard tabs
Column: 1
(MD010, no-hard-tabs)
179-179: Hard tabs
Column: 1
(MD010, no-hard-tabs)
180-180: Hard tabs
Column: 1
(MD010, no-hard-tabs)
181-181: Hard tabs
Column: 1
(MD010, no-hard-tabs)
215-215: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
229-229: Hard tabs
Column: 1
(MD010, no-hard-tabs)
230-230: Hard tabs
Column: 1
(MD010, no-hard-tabs)
231-231: Hard tabs
Column: 1
(MD010, no-hard-tabs)
232-232: Hard tabs
Column: 1
(MD010, no-hard-tabs)
233-233: Hard tabs
Column: 1
(MD010, no-hard-tabs)
269-269: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
283-283: Hard tabs
Column: 1
(MD010, no-hard-tabs)
284-284: Hard tabs
Column: 1
(MD010, no-hard-tabs)
285-285: Hard tabs
Column: 1
(MD010, no-hard-tabs)
286-286: Hard tabs
Column: 1
(MD010, no-hard-tabs)
287-287: Hard tabs
Column: 1
(MD010, no-hard-tabs)
323-323: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
337-337: Hard tabs
Column: 1
(MD010, no-hard-tabs)
338-338: Hard tabs
Column: 1
(MD010, no-hard-tabs)
339-339: Hard tabs
Column: 1
(MD010, no-hard-tabs)
340-340: Hard tabs
Column: 1
(MD010, no-hard-tabs)
341-341: Hard tabs
Column: 1
(MD010, no-hard-tabs)
377-377: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
391-391: Hard tabs
Column: 1
(MD010, no-hard-tabs)
392-392: Hard tabs
Column: 1
(MD010, no-hard-tabs)
393-393: Hard tabs
Column: 1
(MD010, no-hard-tabs)
394-394: Hard tabs
Column: 1
(MD010, no-hard-tabs)
395-395: Hard tabs
Column: 1
(MD010, no-hard-tabs)
431-431: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
445-445: Hard tabs
Column: 1
(MD010, no-hard-tabs)
446-446: Hard tabs
Column: 1
(MD010, no-hard-tabs)
447-447: Hard tabs
Column: 1
(MD010, no-hard-tabs)
448-448: Hard tabs
Column: 1
(MD010, no-hard-tabs)
449-449: Hard tabs
Column: 1
(MD010, no-hard-tabs)
486-486: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
500-500: Hard tabs
Column: 1
(MD010, no-hard-tabs)
501-501: Hard tabs
Column: 1
(MD010, no-hard-tabs)
502-502: Hard tabs
Column: 1
(MD010, no-hard-tabs)
503-503: Hard tabs
Column: 1
(MD010, no-hard-tabs)
536-536: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
550-550: Hard tabs
Column: 1
(MD010, no-hard-tabs)
551-551: Hard tabs
Column: 1
(MD010, no-hard-tabs)
552-552: Hard tabs
Column: 1
(MD010, no-hard-tabs)
553-553: Hard tabs
Column: 1
(MD010, no-hard-tabs)
554-554: Hard tabs
Column: 1
(MD010, no-hard-tabs)
590-590: Tables should be surrounded by blank lines
null
(MD058, blanks-around-tables)
🪛 LanguageTool
pkg/client/README.md
[style] ~302-~302: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...he requirements for the HTTP client are very simple. It must match this interface: ```go t...
(EN_WEAK_ADJECTIVE)
[uncategorized] ~310-~310: When a number forms part of an adjectival compound, use a hyphen.
Context: ...ple example, which adds a client with a 30 second timeout. ```go import ( "net/http" "...
(MISSING_HYPHEN)
[style] ~391-~391: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...
(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~391-~391: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...
(COMMA_COMPOUND_SENTENCE)
🔇 Additional comments (133)
pkg/client/types/date.go (3)
1-2: Be aware that this is a generated file.As indicated by the header comment, this file is generated by Speakeasy. Any modifications should be made through the generator rather than directly editing this file.
12-15: LGTM! TheDatetype is well-designed.The wrapper around
time.Timeprovides a clean approach for JSON date handling in the specific format required.
17-21: Good practice: Interface implementation verification.Using variable assignments to verify interface implementations at compile time is an excellent practice to ensure type compatibility.
pkg/client/auth.go (1)
1-17: LGTM - Auto-generated client structureThe code follows standard Go patterns for client libraries with a clean structure and proper initialization. The constructor properly initializes all fields with the provided configuration.
pkg/api/util_test.go (1)
10-10: LGTM - Successfully updated to v2 libraryThe import path update from go-libs to go-libs/v2 aligns with the PR objective to switch to Go libraries version 2. This change properly follows Go module versioning conventions.
pkg/client/retry/config.go (1)
1-17: LGTM - Well-structured retry configurationThe retry configuration looks well-structured with appropriate fields for implementing exponential backoff. The
BackoffStrategyincludes all necessary parameters, and the top-levelConfigprovides flexibility in retry behavior.The only improvement would be to add documentation comments to clarify the units for time-related fields (milliseconds, seconds?) and the valid values for the
Strategyfield, but since this is auto-generated code, that would need to be addressed in the generator.pkg/client/CONTRIBUTING.md (1)
1-27: Well-structured contribution guidelines for generated codeThe CONTRIBUTING.md file provides clear instructions on the contribution process, emphasizing that direct changes aren't accepted because the repository contains generated code. It effectively outlines how to report issues and what details to include.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
14-14: Unordered list indentation
Expected: 2; Actual: 4(MD007, ul-indent)
pkg/client/types/datetime.go (1)
1-23: LGTM: Properly documented utility functions for time parsingThese time parsing utility functions are clearly documented with appropriate warnings about avoiding their use in production code due to the panic behavior. Since this is generated code (as indicated by the header comment), no changes are needed.
pkg/client/types/pointers.go (1)
1-10: LGTM: Common utility functions for creating pointer typesThese are standard utility functions for creating pointers to primitive types, which are commonly used when working with APIs that require pointer types for optional values. The implementation is clean and concise.
pkg/api/util.go (1)
13-14: LGTM: Updated import paths to v2 of go-libsThe import paths have been correctly updated to use version 2 of the go-libs packages, which aligns with the PR objective of switching to Go libraries version 2.
pkg/api/clients_test.go (4)
11-11: UpdatebundebugImport Path
The update togithub.com/formancehq/go-libs/v2/bun/bundebugis correctly applied, aligning with the new versioning scheme.
13-13: UpdateloggingImport Path
The import for logging now points togithub.com/formancehq/go-libs/v2/loggingas expected.
15-15: UpdatebunconnectImport Path
The modified importgithub.com/formancehq/go-libs/v2/bun/bunconnectreflects the proper migration to version 2.
20-20: UpdatecollectionutilsImport Path
The change to usegithub.com/formancehq/go-libs/v2/collectionutilsensures consistency with the new library version.pkg/api/users_test.go (3)
11-11: UpdatebundebugImport Path in Users Tests
The import now uses the version 2 path (github.com/formancehq/go-libs/v2/bun/bundebug), which is consistent with our current upgrade strategy.
13-13: UpdateloggingImport Path in Users Tests
Updating the logging import to usegithub.com/formancehq/go-libs/v2/loggingis correct and keeps our dependencies consistent.
15-15: UpdatebunconnectImport Path in Users Tests
The change to importgithub.com/formancehq/go-libs/v2/bun/bunconnectis appropriate and aligns with the version upgrade.pkg/oidc/main_test.go (1)
6-10: Update Import Paths for Testing Utilities
The modifications on lines 6–10 update the import paths for logging, docker, utils, and pgtesting to their version 2 counterparts. This ensures compatibility with the new go-libs/v2 improvements.pkg/oidc/oidc_test.go (3)
18-18: UpdatebundebugImport Path in OIDC Tests
The import for bundebug has been updated to use the versioned path, which is in line with our overall library update.
21-21: UpdateloggingImport Path in OIDC Tests
The logging import now correctly points togithub.com/formancehq/go-libs/v2/logging, ensuring consistency across tests.
24-24: UpdatebunconnectImport Path in OIDC Tests
The modification to importgithub.com/formancehq/go-libs/v2/bun/bunconnectis properly made to conform with the new library version.pkg/client/README.md (8)
1-9: New README.md: Initial Documentation and Badges
The introductory section with badges and the welcome message is informative. The use of HTML for badge display is acceptable. Ensure that the badge URLs and parameters are maintained if the upstream icons or assets change.
11-18: Clear Welcome Message and Next Steps
The welcome message and checklist provide a helpful onboarding guide. Once the SDK is production-ready, remember to remove the checklist instructions as noted.
22-25: SDK Installation Section
The installation instruction usinggo getis clear and concise.
27-33: SDK Example Usage Section
The sample code demonstrates typical usage well. Ensure that all sample configuration values (e.g., ClientID and ClientSecret) are replaced with actual credentials when integrated.
81-91: Retries Section: Code Example for Custom Retry Strategy
The documentation on overriding the default retry strategy is comprehensive. The provided Go snippet clearly outlines the option usage.
129-137: Global Retry Configuration Guidance
The example for setting a global retry configuration is clear and beneficial to SDK users.
173-178: Error Handling Section Explanation
The error handling guidelines and example effectively illustrate how to process errors using SDK-specific types.
220-229: Server Selection Section
The instructions for overriding the default server—both by index and URL—are straightforward. The table and examples should help users correctly configure their client.pkg/api/module.go (1)
8-8: Imports updated to go-libs/v2All these lines update the imports to the v2 version of the
go-libsmodules. This is aligned with the ongoing upgrade in the PR. Ensure that all downstream references (e.g., function calls, constants) are properly migrated and that you've tested for any breaking changes introduced in v2.Also applies to: 12-12, 13-13, 14-14
pkg/client/internal/utils/json.go (3)
117-245: Review ofUnmarshalJSONfunction (lines 117-245)
- Disallowing unknown fields: The branch that checks for unknown fields at lines 205-207 is clear. Good practice to handle unknown fields explicitly or to allow them under
additionalProperties.- Const field check: The logic at lines 164-176 consistently enforces the immutable expectation for fields tagged with
const. It helps ensure data integrity, so this is a good approach.- Default values: The code (lines 183-188) sets default values for missing fields. This is helpful but can sometimes mask erroneous input. Keep an eye on potential misconfigurations if defaulting is used in unexpected scenarios.
247-349: Review ofmarshalValuefunction (lines 247-349)
- BigInt, decimal, time: Handling for specialized numeric and temporal types is thorough, though code paths can become complex. Consider logging or tracing for debugging if further expansions are planned.
- Nil-checking: The code checks for
isNiland properly returns"null"or applies default values. This is consistent and helps guard against panics.
391-619: Review ofunmarshalValuefunction (lines 391-619)
- Pointer management: You do a careful job unwrapping pointers before type-specific parsing. Just ensure that any future refactoring of pointer logic remains consistent.
- Multiple numeric formats: Handling
"number"vs."string"format for floats and ints is beneficial for flexible JSON input. The error messages are reasonably descriptive for debugging.- Complex data: The branching for maps, arrays, and specialized types (time, big.Int, decimal, etc.) is comprehensive. Consider adding integration tests covering edge cases (e.g., invalid numeric strings, partial time formats) to ensure all custom cases parse correctly.
pkg/client/.gitattributes (1)
1-2: .gitattributes additionMarking
*.goaslinguist-generated=falsehelps ensure the Go code is recognized as primary code by GitHub. This is good practice for a codebase with heavily generated files. No issues here.pkg/client/docs/models/operations/readuserrequest.md (1)
1-8: New Documentation for ReadUserRequest Looks GoodThis new documentation file clearly defines the
ReadUserRequestmodel and its requiredUserIDfield. The markdown table is well formatted and easily understandable.pkg/client/docs/models/components/updateclientresponse.md (1)
1-8: UpdateClientResponse Documentation is Well-StructuredThe file effectively outlines the
UpdateClientResponsemodel by defining theDatafield with its corresponding type and requirement status. Ensure that this documentation remains in sync with the underlying Go model as it evolves.pkg/client/docs/models/operations/readclientrequest.md (1)
1-8: ReadClientRequest Documentation is Clear and ConciseThis new documentation file for
ReadClientRequestproperly documents theClientIDfield along with its type and requirement. The table format is consistent with other documentation files.pkg/client/docs/models/components/createsecretresponse.md (1)
1-8: CreateSecretResponse Documentation Looks SolidThe documentation for
CreateSecretResponseeffectively presents the model information using a clean and consistent table format. The link reference tocomponents.Secretis helpful for further context.pkg/client/docs/models/operations/deleteclientrequest.md (1)
1-8: Clear and Concise Documentation for DeleteClientRequestThis new markdown file clearly defines the
DeleteClientRequestmodel. The table layout is easy to follow, and the use of the required checkmark for theClientIDfield is appropriate.pkg/client/docs/models/components/createclientresponse.md (1)
1-8: Well-Structured CreateClientResponse DocumentationThe file effectively presents the
CreateClientResponsemodel using a straightforward table layout. The field information is clear and the link referencing thecomponents.Clientmodel is properly formatted.pkg/client/docs/models/operations/deletesecretrequest.md (1)
1-9: Accurate and Detailed DeleteSecretRequest DocumentationThe file provides a clear and precise description for the
DeleteSecretRequestoperation. With bothClientIDandSecretIDmarked as required, the table effectively communicates the necessary information.pkg/client/docs/models/operations/deletesecretresponse.md (1)
1-8: Solid DeleteSecretResponse DocumentationThe markdown document clearly specifies the
DeleteSecretResponsemodel and details the mandatoryHTTPMetafield. The referenced link tocomponents.HTTPMetadatais consistent with the rest of the documentation, ensuring clarity and uniformity.pkg/client/docs/models/components/readuserresponse.md (1)
1-8: Clear and Structured Documentation for ReadUserResponse
The markdown file clearly explains theReadUserResponsemodel with a well-formatted table for its fields. The hyperlink to theUsermodel is appropriately provided for further context.pkg/client/docs/models/operations/deleteclientresponse.md (1)
1-8: Consistent and Informative Documentation for DeleteClientResponse
The content is well laid out, providing a clear table that specifies the required fields, types, and descriptions. The reference toHTTPMetadatais consistent with similar models.pkg/client/docs/models/operations/getoidcwellknownsresponse.md (1)
1-8: Concise and Consistent Documentation for GetOIDCWellKnownsResponse
This new documentation file is concise and follows the established table format. The reference to[components.HTTPMetadata]maintains consistency across similar response models.pkg/client/docs/models/components/readclientresponse.md (1)
1-8: Documentation Clarity and Formatting
The markdown structure is clear and the table is properly formatted. The file effectively documents theReadClientResponsemodel. You might consider expanding the "Description" column in the future if more contextual details become necessary.pkg/client/docs/models/operations/updateclientrequest.md (1)
1-9: Consistent and Clear Documentation for UpdateClientRequest
The file provides a clear, concise tabular documentation of theUpdateClientRequestmodel. All fields and their attributes are well-presented. Please verify that the link forUpdateClientRequestis pointing to the intended document and update if necessary.pkg/client/docs/models/operations/listusersresponse.md (1)
1-9: Organized Documentation for ListUsersResponse
The markdown file is organized and clear, with an appropriate breakdown of fields and their required statuses. Ensure that naming conventions (for instance, betweenHTTPMetaandListUsersResponse) stay consistent with other parts of the SDK documentation.pkg/client/docs/models/operations/createsecretresponse.md (1)
1-9: Documentation for CreateSecretResponse is Clear and Consistent
The new markdown file provides a concise and well-formatted table that outlines the fields of the CreateSecretResponse model. Please verify that the relative link paths (e.g., for[components.HTTPMetadata]and[*components.CreateSecretResponse]) are correct with respect to your project structure.pkg/client/docs/models/operations/readuserresponse.md (1)
1-9: Documentation for ReadUserResponse is Well-Structured
This file presents a clear table format that defines the ReadUserResponse model, including the associated fields and their requirements. Ensure that the relative links and field names are consistent with the other documentation files in the SDK.pkg/client/docs/models/components/createsecretrequest.md (1)
1-9: Component Documentation for CreateSecretRequest is Complete
The document details the CreateSecretRequest model with a straightforward table that includes theNameandMetadatafields. For future clarity, consider adding brief field descriptions or usage contexts if needed.pkg/client/docs/models/components/httpmetadata.md (1)
1-9: HTTPMetadata Documentation is Thorough and Precise
The markdown file clearly defines the HTTPMetadata structure with detailed field descriptions and appropriate external reference links. Please verify that the URLs for[ *http.Response ]and[ *http.Request ]correctly resolve to the intended resources.pkg/client/models/components/serverinfo.go (1)
1-14: Clean implementation with proper nil handling.The
ServerInfostruct andGetVersionmethod follow good Go practices. The nil check in the getter method prevents potential nil pointer dereferences, which is excellent defensive programming.pkg/client/internal/hooks/registration.go (1)
1-18: LGTM - Good hook registration structureThis is a clean, well-documented hooks initialization structure. The file clearly explains that it's generated once and can be freely modified, with hooks being registered per SDK instance.
The commented examples provide a good starting point for implementing custom hooks in your authentication system. Consider implementing specific hooks for your OAuth2 flow once you have the requirements finalized.
pkg/client/models/components/readclientresponse.go (1)
1-15: LGTM - Clean implementation with nil safetyThe ReadClientResponse implementation is well-structured and includes a nil-safe getter method, which is a good practice for preventing nil pointer dereferences.
Since this is auto-generated code, no changes are needed. The implementation follows good Go practices for handling optional fields in API responses.
pkg/client/models/components/createclientresponse.go (1)
1-14: Code looks good!This auto-generated code correctly implements a response structure for client creation with proper null safety in the
GetData()method.pkg/client/models/components/listusersresponse.go (1)
1-14: Code looks good!This auto-generated code correctly implements a response structure for listing users with proper null safety in the
GetData()method.pkg/client/models/components/readuserresponse.go (1)
1-14: Auto-generated code follows best practicesThe
ReadUserResponsestruct and its associatedGetData()method are well-implemented with proper nil checks to prevent panic errors. The struct uses appropriate JSON tags with theomitemptyoption.Note that this file is generated by Speakeasy and should not be manually edited, as indicated by the comment at the top.
pkg/client/models/components/updateclientresponse.go (1)
1-14: Auto-generated code follows best practicesThe
UpdateClientResponsestruct and its associatedGetData()method are well-implemented with appropriate nil checks to prevent panic errors. The struct uses proper JSON tags with theomitemptyoption.Note that this file is generated by Speakeasy and should not be manually edited, as indicated by the comment at the top.
pkg/client/models/components/listclientsresponse.go (1)
1-14: Auto-generated code follows best practicesThe
ListClientsResponsestruct and its associatedGetData()method are well-implemented with proper nil checks to prevent panic errors. The struct uses appropriate JSON tags with theomitemptyoption.Note that this file is generated by Speakeasy and should not be manually edited, as indicated by the comment at the top.
pkg/client/models/components/createsecretresponse.go (1)
1-14: Code structure looks goodThis auto-generated code follows best practices with proper nil-checking in the getter method and appropriate JSON field tags. The structure and implementation are clean and well-organized.
cmd/root.go (1)
4-4: Import paths correctly updated to v2The import paths have been properly updated from v1 to v2 of the go-libs package, which aligns with the PR objective of switching to Go libraries version 2.
Also applies to: 7-7
pkg/client/models/components/user.go (1)
1-30: User model implementation looks goodThis auto-generated code follows best practices with proper nil-checking in all getter methods, appropriate use of pointers for optional fields, and consistent JSON field tags.
pkg/client/models/operations/getoidcwellknowns.go (1)
1-18: OIDC well-knowns operation looks well-structuredThis auto-generated code correctly implements the response struct for OIDC well-known endpoints with proper nil-checking and field tagging. The implementation is clean and follows consistent patterns with the rest of the codebase.
pkg/client/models/components/httpmetadata.go (1)
1-29: Well-structured HTTP metadata wrapperThis auto-generated file creates a clean abstraction for HTTP metadata with proper nil checks in the getter methods to prevent nil pointer dereferences. The
json:"-"tags appropriately prevent serializing potentially large HTTP objects.Just note that
ResponseandRequestfields may contain sensitive data (headers, cookies, tokens, etc.), so care should be taken when logging or exposing this metadata.pkg/client/models/operations/createclient.go (1)
1-28: Cleanly structured response object with proper nil handlingThis auto-generated response structure appropriately encapsulates both HTTP metadata and the actual response payload. The getter methods correctly handle nil receivers.
Note that there might be some developer confusion with the naming - the struct itself and one of its fields share the same name
CreateClientResponse(differentiated only by package). This is a common pattern in generated code but something to be aware of when using the SDK.pkg/client/models/components/clientsecret.go (1)
1-39: Well-designed secret representation with security in mindThis auto-generated struct appropriately represents a client secret with good security practices - notably storing only the
LastDigitsrather than the full secret value. The getter methods properly handle nil receivers, and theMetadatafield provides a flexible way to extend the model with additional information.pkg/client/models/components/secret.go (1)
1-47: Review security implications of the Clear fieldThis auto-generated struct includes both
LastDigitsand the fullClearvalue of the secret. While this is likely needed for initially providing the secret to the caller after creation, ensure this sensitive data is:
- Only returned during creation operations
- Never logged
- Not persisted in any way after initial use
- Transmitted over secure channels
Consider reviewing where this struct is used in your system to verify secrets are handled securely.
pkg/api/authorization/accesstoken_test.go (1)
12-17: Library imports updated to v2.The imports have been correctly updated to use version 2 of the go-libs library, which aligns with the PR objective to switch to Go libraries version 2.
pkg/client/models/components/createsecretrequest.go (3)
1-8: LGTM: CreateSecretRequest struct is well-defined.The struct correctly defines the necessary fields for creating a secret with proper JSON tags. The
metadatafield is appropriately marked as optional withomitempty.
10-15: LGTM: Proper nil-checking in GetName method.The GetName method includes appropriate nil checking to prevent nil pointer dereferences.
17-22: LGTM: Proper nil-checking in GetMetadata method.The GetMetadata method includes appropriate nil checking to prevent nil pointer dereferences.
pkg/client/models/operations/listusers.go (3)
9-13: LGTM: ListUsersResponse struct is well-defined.The struct properly separates HTTP metadata from the actual response data, with appropriate JSON tags to control serialization.
15-20: LGTM: Proper nil-checking in GetHTTPMeta method.The GetHTTPMeta method includes appropriate nil checking and returns a default empty object instead of nil.
22-27: LGTM: Proper nil-checking in GetListUsersResponse method.The GetListUsersResponse method includes appropriate nil checking to prevent nil pointer dereferences.
pkg/client/docs/sdks/v1/README.md (12)
1-17: LGTM: README provides a clear overview of available operations.The documentation clearly lists all available operations in the Auth SDK, making it easy for developers to understand the API surface.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3(MD001, heading-increment)
18-67: LGTM: GetOIDCWellKnowns documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
28-28: Hard tabs
Column: 1(MD010, no-hard-tabs)
29-29: Hard tabs
Column: 1(MD010, no-hard-tabs)
30-30: Hard tabs
Column: 1(MD010, no-hard-tabs)
31-31: Hard tabs
Column: 1(MD010, no-hard-tabs)
64-64: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
68-117: LGTM: GetServerInfo documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
78-78: Hard tabs
Column: 1(MD010, no-hard-tabs)
79-79: Hard tabs
Column: 1(MD010, no-hard-tabs)
80-80: Hard tabs
Column: 1(MD010, no-hard-tabs)
81-81: Hard tabs
Column: 1(MD010, no-hard-tabs)
114-114: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
118-167: LGTM: ListClients documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
128-128: Hard tabs
Column: 1(MD010, no-hard-tabs)
129-129: Hard tabs
Column: 1(MD010, no-hard-tabs)
130-130: Hard tabs
Column: 1(MD010, no-hard-tabs)
131-131: Hard tabs
Column: 1(MD010, no-hard-tabs)
164-164: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
168-218: LGTM: CreateClient documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
178-178: Hard tabs
Column: 1(MD010, no-hard-tabs)
179-179: Hard tabs
Column: 1(MD010, no-hard-tabs)
180-180: Hard tabs
Column: 1(MD010, no-hard-tabs)
181-181: Hard tabs
Column: 1(MD010, no-hard-tabs)
215-215: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
219-272: LGTM: ReadClient documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
229-229: Hard tabs
Column: 1(MD010, no-hard-tabs)
230-230: Hard tabs
Column: 1(MD010, no-hard-tabs)
231-231: Hard tabs
Column: 1(MD010, no-hard-tabs)
232-232: Hard tabs
Column: 1(MD010, no-hard-tabs)
233-233: Hard tabs
Column: 1(MD010, no-hard-tabs)
269-269: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
273-326: LGTM: UpdateClient documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
283-283: Hard tabs
Column: 1(MD010, no-hard-tabs)
284-284: Hard tabs
Column: 1(MD010, no-hard-tabs)
285-285: Hard tabs
Column: 1(MD010, no-hard-tabs)
286-286: Hard tabs
Column: 1(MD010, no-hard-tabs)
287-287: Hard tabs
Column: 1(MD010, no-hard-tabs)
323-323: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
327-380: LGTM: DeleteClient documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
337-337: Hard tabs
Column: 1(MD010, no-hard-tabs)
338-338: Hard tabs
Column: 1(MD010, no-hard-tabs)
339-339: Hard tabs
Column: 1(MD010, no-hard-tabs)
340-340: Hard tabs
Column: 1(MD010, no-hard-tabs)
341-341: Hard tabs
Column: 1(MD010, no-hard-tabs)
377-377: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
381-434: LGTM: CreateSecret documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
391-391: Hard tabs
Column: 1(MD010, no-hard-tabs)
392-392: Hard tabs
Column: 1(MD010, no-hard-tabs)
393-393: Hard tabs
Column: 1(MD010, no-hard-tabs)
394-394: Hard tabs
Column: 1(MD010, no-hard-tabs)
395-395: Hard tabs
Column: 1(MD010, no-hard-tabs)
431-431: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
435-489: LGTM: DeleteSecret documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
445-445: Hard tabs
Column: 1(MD010, no-hard-tabs)
446-446: Hard tabs
Column: 1(MD010, no-hard-tabs)
447-447: Hard tabs
Column: 1(MD010, no-hard-tabs)
448-448: Hard tabs
Column: 1(MD010, no-hard-tabs)
449-449: Hard tabs
Column: 1(MD010, no-hard-tabs)
486-486: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
490-539: LGTM: ListUsers documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
500-500: Hard tabs
Column: 1(MD010, no-hard-tabs)
501-501: Hard tabs
Column: 1(MD010, no-hard-tabs)
502-502: Hard tabs
Column: 1(MD010, no-hard-tabs)
503-503: Hard tabs
Column: 1(MD010, no-hard-tabs)
536-536: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
540-593: LGTM: ReadUser documentation is comprehensive.The documentation for this operation includes a clear description, complete example code, parameter details, and response information.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
550-550: Hard tabs
Column: 1(MD010, no-hard-tabs)
551-551: Hard tabs
Column: 1(MD010, no-hard-tabs)
552-552: Hard tabs
Column: 1(MD010, no-hard-tabs)
553-553: Hard tabs
Column: 1(MD010, no-hard-tabs)
554-554: Hard tabs
Column: 1(MD010, no-hard-tabs)
590-590: Tables should be surrounded by blank lines
null(MD058, blanks-around-tables)
pkg/client/models/operations/listclients.go (1)
1-27: LGTM: Well-structured generated code.This file follows a clean pattern for API client response models with proper nil checks in getter methods and clear separation of HTTP metadata from response data.
pkg/client/models/operations/getserverinfo.go (1)
1-27: LGTM: Well-structured generated code.This file follows a consistent pattern with the rest of the client package, implementing proper nil checks in getter methods and maintaining a clear separation between HTTP metadata and the actual response data.
pkg/client/models/operations/deleteclient.go (1)
1-31: Code looks good - appropriate request/response structure with nil safetyThe DeleteClient operation models are well-structured with proper nil checks in the getter methods to prevent potential nil pointer dereferences. The struct field tagging for API path parameters is correctly implemented.
pkg/client/internal/utils/contenttype.go (1)
11-37: Well-implemented content type matching functionThe MatchContentType function handles various cases appropriately:
- Sets default content type when empty
- Handles exact matches and wildcards
- Properly parses media types with error handling
- Correctly implements partial wildcard matching (type/* and */subtype)
The implementation is robust and follows best practices for MIME type handling.
pkg/client/models/sdkerrors/sdkerror.go (2)
10-15: Good error type design with comprehensive contextThe SDKError struct includes all the necessary information for effective error handling in an SDK context - message, status code, response body, and the raw HTTP response, allowing consumers to make informed decisions based on the error details.
17-35: Well-implemented error interface with good formattingThe error implementation properly satisfies Go's error interface and formats error messages in a helpful way, including both status code and response body when available. The constructor ensures consistent creation of error instances.
pkg/client/models/components/security.go (3)
9-13: Appropriately structured security componentThe Security struct is properly defined with the necessary fields for OAuth2 client credentials authentication, with appropriate struct tags for the security scheme.
15-24: JSON marshaling looks correctThe custom marshaling and unmarshaling methods are delegating to utility functions, which is appropriate. The error handling in UnmarshalJSON looks good.
26-42: Getter methods with proper nil checksThe getter methods for ClientID and ClientSecret properly handle nil receivers, preventing potential nil pointer dereferences. The GetTokenURL method returns the constant token URL path as expected.
pkg/client/internal/utils/form.go (1)
1-117: Code looks well-implemented and follows best practices.This is auto-generated code by Speakeasy with solid implementation of form data handling. The utility functions
populateFormandparseDelimitedArrayhandle various data types appropriately with proper nil-checks and robust type handling. The reflection-based approach is well-designed for the use case.pkg/client/models/operations/deletesecret.go (1)
1-40: Implementation follows good API design patterns.This auto-generated code properly defines the request and response structures for secret deletion operations, with appropriate nil-safe accessor methods. The field annotations for path parameters are correctly specified, and the HTTP metadata handling follows consistent patterns.
pkg/api/authorization/main_test.go (1)
6-10: Import paths correctly updated to v2.The import paths have been properly updated from
github.com/formancehq/go-libs/togithub.com/formancehq/go-libs/v2/which aligns with the PR objective of switching to Go libraries version 2. This follows Go modules versioning conventions where major version changes are reflected in the import path.pkg/client/models/operations/readuser.go (1)
1-40: Good implementation of request/response structures.This auto-generated code properly defines the structures for user read operations with appropriate nil-safe accessor methods. The field annotations and documentation are clear, and the implementation follows consistent patterns for handling HTTP metadata and response data.
pkg/client/models/operations/readclient.go (3)
1-3: Auto-generated header – no concerns.This is boilerplate code generated by Speakeasy. No action needed.
5-7: Imports look good.The import of
componentsfrom"github.com/formancehq/auth/pkg/client/models/components"aligns with the package structure and project conventions.
27-39: Accessor methods appear consistent.The methods
GetHTTPMeta()andGetReadClientResponse()follow the established nil-check convention. Implementation looks correct and consistent with your patterns.pkg/client/internal/utils/headers.go (2)
1-13: Header population logic is clear.The
PopulateHeadersfunction is straightforward. It leverages reflection-based population effectively for a flexible schema. No immediate concerns here.
20-53: Cautiously handle skip fields.The
populateHeadersfunction handles reflection-based population with skip logic. Carefully ensure that omitted fields are correctly documented. Otherwise, logic seems robust for dynamic header insertion.pkg/client/internal/utils/security.go (3)
1-24: Security-related constants and struct are fine.The
securityTagdefinition and related constants are straightforward, clearly establishing the security model metadata.
26-91: Security population is well-structured.
PopulateSecurityhas a coherent flow for applying different security attributes. The reflection usage allows dynamic binding, though it can be costly under high load. Performance testing might be warranted, but the approach is valid.
93-148: Scheme parsing appears consistent.
handleSecurityOptionandparseSecuritySchemehandle multiple authentication schemes effectively. The structure is flexible and accommodates expansions, such as additional tokens or basic credentials.pkg/api/main_test.go (1)
6-10: Import paths updated to v2 of go-libs package.The import paths have been properly updated from version 1 to version 2 of the go-libs library. This change aligns with the PR objective of switching to Go libraries version 2.
pkg/client/models/components/client.go (3)
1-2: Generated code disclaimer noted.This file is auto-generated by Speakeasy, which is correctly indicated in the header comment.
5-16: Client struct definition well-organized.The Client struct is well-defined with appropriate JSON tags and field types. The required fields (Name and ID) use non-pointer types while optional fields use pointer types or slices/maps that can be nil.
18-86: Getter methods follow consistent patterns with proper nil checks.All getter methods consistently check if the receiver is nil before attempting to access fields, returning appropriate default values (nil for pointer/slice/map types and empty string for non-pointer string types). This prevents potential nil pointer dereference issues.
pkg/client/internal/utils/retries.go (3)
20-24: Deprecation notices for type aliases.Good practice to include deprecation notices for the type aliases, directing users to use the types from the retry package directly.
74-96: Status code handling logic uses string format for flexibility.The status code handling supports both specific codes (e.g., "404") and ranges using X wildcards (e.g., "4XX"). This provides flexibility but adds complexity. The implementation correctly handles both formats.
31-109:Details
❓ Verification inconclusive
Retry mechanism implementation is comprehensive but complex.
The retry implementation handles various scenarios including:
- Exponential backoff configuration
- Response cleanup (closing response bodies)
- Context cancellation
- Error classification (temporary vs. permanent)
- Status code validation
While the implementation is thorough, the complexity could make debugging challenging. Consider comprehensive testing of different retry scenarios.
🏁 Script executed:
#!/bin/bash # Check if there are tests for this retry mechanism fd "retries_test.go" --type f pkg/clientLength of output: 40
Review and Validate Comprehensive Testing for Retry Mechanism
The retry implementation is comprehensive—it carefully handles exponential backoff, response cleanup, context cancellation, error classification, and status code validations. However, an initial search did not reveal any dedicated tests (e.g., no
retries_test.gofound) covering these scenarios. Please ensure that extensive, scenario-specific tests are in place to cover:
- Exponential backoff and configuration validation.
- Correct closure of response bodies on successive retries.
- Proper handling of context cancellation and termination.
- Differentiation between temporary and permanent errors.
- Accurate response behavior based on various status codes.
If these tests do not exist, consider adding them to safeguard against potential regressions given the complexity of the retry logic.
pkg/client/models/operations/createsecret.go (3)
9-13: CreateSecretRequest struct uses clear field annotations.The struct properly uses annotation tags to indicate how fields should be bound in HTTP requests:
ClientIDis marked as a path parameter with specific style and explode settingsCreateSecretRequestis marked as a JSON request body
29-33: CreateSecretResponse struct excludes HTTPMeta from JSON serialization.The HTTPMeta field is correctly excluded from JSON serialization using the
json:"-"tag, which is appropriate for metadata that shouldn't be part of the API response payload.
15-47: Getter methods include proper nil checks.All getter methods properly check if the receiver is nil before accessing fields, which prevents potential nil pointer dereference issues. The methods also return appropriate default values when the receiver is nil.
pkg/client/models/operations/updateclient.go (1)
1-48: All good—Generated code is consistent and appears correct.This file uses conventional patterns (nil-checking getters, straightforward request/response structs). Since it is generated by Speakeasy and marked “DO NOT EDIT,” manual modifications might be overwritten. No functional or security issues found.
pkg/client/models/components/createclientrequest.go (1)
1-71: Looks good—No issues detected in generated code.Fields and getters follow standard patterns for safe access. As this is generated code, manual edits could be overridden in the future, so proceed without changes.
pkg/client/models/components/updateclientrequest.go (2)
5-14: Well-structured client update request model.This structure is well-designed with appropriate JSON tags. The
Namefield is required (noomitempty), while other fields are optional.
16-21: LGTM: Robust getter methods with nil checks.All getter methods properly check for nil receivers before attempting to access fields, which prevents potential nil pointer panics at runtime.
Also applies to: 23-28, 30-35, 37-42, 44-49, 51-56, 58-63, 65-70
pkg/client/models/operations/options.go (2)
14-20: Well-defined option constants.These constants provide a clear enumeration of supported options, which improves code readability and maintainability.
33-39: Clean Options struct design.The Options struct is well-organized with pointer fields that allow for optional values.
pkg/client/internal/utils/queryparams.go (2)
20-43: Good error handling in the PopulateQueryParams function.The function properly handles existing query parameters and cascades errors from the helper functions.
76-110: Well-implemented serialization support.The code correctly handles different serialization styles (deepObject, form, pipeDelimited) with appropriate error handling for unsupported styles.
pkg/client/internal/utils/utils.go (1)
36-46: Solid error handling in UnmarshalJsonFromResponseBody.The function properly captures and wraps errors from reading the response body and unmarshalling JSON, which will make debugging easier.
cmd/serve.go (1)
13-29:Details
❓ Verification inconclusive
Confirm version pinning for the new
v2imports.
All references togithub.com/formancehq/go-libs/v2/*appear consistent. However, please ensure that your Go modules (go.modandgo.sum) accurately pin the library version to avoid unexpected breaking changes.
🏁 Script executed:
#!/bin/bash # Confirm references to go-libs/v2 are pinned in go.mod rg 'go-libs/v2' -A 3 cat go.modLength of output: 8677
Verify Version Pinning for go-libs v2 in Go Modules
The references togithub.com/formancehq/go-libs/v2/*appear consistent across the codebase. However, our attempt to check the module file at the repository root (viacat go.mod) did not locate a file. Please ensure that your project’s Go modules—whether located in the repository root or in submodules—explicitly pin the required version of allv2libraries to prevent unexpected breaking changes.
- Confirm that a
go.mod(and correspondinggo.sum) exists in the appropriate directory.- Verify that the pinned version for
github.com/formancehq/go-libs/v2/*is correctly specified in those module files.pkg/client/v1.go (1)
1-2: Generated code acknowledgment.
This file is marked “DO NOT EDIT,” indicating it is generated by Speakeasy. Substantial manual modifications may be overwritten. Future updates should happen at the source generator or via scripts.pkg/client/internal/utils/requestbody.go (1)
28-39: Looks good for optional request bodies
Implementation ensures optional requests are allowed. Solid approach.pkg/client/internal/hooks/clientcredentials.go (3)
39-43: Ensure thread-safe session management
sessions map[string]*sessioncan be accessed by multiple goroutines. Use a mutex or sync.Map to prevent data races.
94-119: Verify token refresh approach
Deleting the session on 401 forces a fresh token request. If partial session data remains valid, a refresh procedure might be more efficient.
249-251: Check the 60-second token safety margin
Tokens are treated as expired if within 60 seconds of their expiration. Confirm this buffer period aligns with your service’s recommended best practices.
|
|
||
| auth "github.com/formancehq/auth/pkg" | ||
| _ "github.com/formancehq/go-libs/api" | ||
| _ "github.com/formancehq/go-libs/v2/api" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Import path correctly updated to v2.
This change aligns with the PR objective to switch to Go libraries version 2. The import path has been properly updated to use the versioned path with /v2/ which follows Go modules versioning conventions.
🏁 Script executed:
#!/bin/bash
# Verify that this import change is consistent across the codebase
# to ensure all imports of go-libs have been updated to v2
# Search for any remaining v1 imports
echo "Checking for any remaining v1 imports of go-libs:"
rg -g "*.go" "github.com/formancehq/go-libs/[^v]" --no-filename | wc -l
echo "Number of imports that should be updated to v2 (should be 0)"Length of output: 315
Inconsistent Go Libraries Import Versions Detected
- The reviewed file
pkg/api/clients.gocorrectly uses the updated import path (github.com/formancehq/go-libs/v2/api), which aligns with the PR objective. - However, the verification script discovered one remaining instance of a go-libs import that does not include the
/v2suffix, indicating a v1 usage. - Please run the following detailed search to pinpoint the file and line for that occurrence and update it accordingly:
Once the location is identified, update the import to use the /v2/ path to ensure consistency across the codebase.
🏁 Script executed:
#!/bin/bash
echo "Searching for detailed occurrence of v1 imports of go-libs:"
rg -g '*.go' 'github.com/formancehq/go-libs/[^v]' --line-numberLength of output: 398
Action Required: Update Inconsistent Import in Test File
- The import in
pkg/api/clients.gohas correctly been updated to usegithub.com/formancehq/go-libs/v2/api, aligning with the PR objective. - However, verification revealed an outdated v1 import in
test/e2e/jwt_bearer_test.goat line 18:- Current:
. "github.com/formancehq/go-libs/collectionutils" - Suggested: Update to
. "github.com/formancehq/go-libs/v2/collectionutils"(if the v2 package layout applies) to ensure consistency.
- Current:
Please update the import in the test file accordingly.
| # UpdateClientRequest | ||
|
|
||
|
|
||
| ## Fields | ||
|
|
||
| | Field | Type | Required | Description | | ||
| | ------------------------ | ------------------------ | ------------------------ | ------------------------ | | ||
| | `Public` | **bool* | :heavy_minus_sign: | N/A | | ||
| | `RedirectUris` | []*string* | :heavy_minus_sign: | N/A | | ||
| | `Description` | **string* | :heavy_minus_sign: | N/A | | ||
| | `Name` | *string* | :heavy_check_mark: | N/A | | ||
| | `Trusted` | **bool* | :heavy_minus_sign: | N/A | | ||
| | `PostLogoutRedirectUris` | []*string* | :heavy_minus_sign: | N/A | | ||
| | `Metadata` | map[string]*any* | :heavy_minus_sign: | N/A | | ||
| | `Scopes` | []*string* | :heavy_minus_sign: | N/A | No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Field type formatting inconsistencies and missing descriptions.
This documentation appears to have two issues:
- The type formatting contains inconsistent asterisk placement (e.g.,
**bool*,[]*string*), which could confuse readers about the actual types. - All fields have "N/A" descriptions, limiting the usefulness of this documentation.
The type formatting should follow a consistent pattern, e.g., *bool for pointer to boolean, []string for string slice, etc. The inconsistent placement of asterisks suggests a potential issue in the documentation generation process.
Consider enhancing the documentation to include meaningful descriptions for each field, especially:
- What
Publicmeans for a client - The purpose of
RedirectUrisandPostLogoutRedirectUris - What
Trustedindicates about the client - What kind of data should be included in
Metadata - What values are expected in
Scopes
This would greatly improve developer experience when using this API.
| | Field | Type | Required | Description | | ||
| | -------------------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------- | | ||
| | `Public` | **bool* | :heavy_minus_sign: | N/A | | ||
| | `RedirectUris` | []*string* | :heavy_minus_sign: | N/A | | ||
| | `Description` | **string* | :heavy_minus_sign: | N/A | | ||
| | `Name` | *string* | :heavy_check_mark: | N/A | | ||
| | `Trusted` | **bool* | :heavy_minus_sign: | N/A | | ||
| | `PostLogoutRedirectUris` | []*string* | :heavy_minus_sign: | N/A | | ||
| | `Metadata` | map[string]*any* | :heavy_minus_sign: | N/A | | ||
| | `Scopes` | []*string* | :heavy_minus_sign: | N/A | | ||
| | `ID` | *string* | :heavy_check_mark: | N/A | | ||
| | `Secrets` | [][components.ClientSecret](../../models/components/clientsecret.md) | :heavy_minus_sign: | N/A | No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Missing meaningful field descriptions.
All field descriptions show "N/A", which doesn't provide useful information to developers using this model. Consider adding descriptive text for each field to explain its purpose and usage.
| // WithOperationTimeout allows setting the request timeout applied for an operation. | ||
| func WithOperationTimeout(timeout time.Duration) Option { | ||
| return func(opts *Options, supportedOptions ...string) error { | ||
| if !utils.Contains(supportedOptions, SupportedOptionRetries) { | ||
| return ErrUnsupportedOption | ||
| } | ||
|
|
||
| opts.Timeout = &timeout | ||
| return nil | ||
| } | ||
| } |
There was a problem hiding this comment.
Fix incorrect option verification in WithOperationTimeout.
The function is checking for the wrong option support flag. It's checking for retry support when setting a timeout.
- if !utils.Contains(supportedOptions, SupportedOptionRetries) {
+ if !utils.Contains(supportedOptions, SupportedOptionTimeout) {
return ErrUnsupportedOption
}📝 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.
| // WithOperationTimeout allows setting the request timeout applied for an operation. | |
| func WithOperationTimeout(timeout time.Duration) Option { | |
| return func(opts *Options, supportedOptions ...string) error { | |
| if !utils.Contains(supportedOptions, SupportedOptionRetries) { | |
| return ErrUnsupportedOption | |
| } | |
| opts.Timeout = &timeout | |
| return nil | |
| } | |
| } | |
| // WithOperationTimeout allows setting the request timeout applied for an operation. | |
| func WithOperationTimeout(timeout time.Duration) Option { | |
| return func(opts *Options, supportedOptions ...string) error { | |
| if !utils.Contains(supportedOptions, SupportedOptionTimeout) { | |
| return ErrUnsupportedOption | |
| } | |
| opts.Timeout = &timeout | |
| return nil | |
| } | |
| } |
| cmd.Flags().String(DelegatedIssuerFlag, "", "Delegated OIDC issuer") | ||
| cmd.Flags().String(DelegatedClientIDFlag, "", "Delegated OIDC client id") | ||
| cmd.Flags().String(DelegatedClientSecretFlag, "", "Delegated OIDC client secret") | ||
| cmd.Flags().String(BaseUrlFlag, "http://localhost:8080", "Base service url") | ||
| cmd.Flags().String(SigningKeyFlag, defaultSigningKey, "Signing key") | ||
| cmd.Flags().String(ListenFlag, ":8080", "Listening address") | ||
| cmd.Flags().String(ConfigFlag, "", "Config file name without extension") |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid embedding default signing key in source code.
Providing a production signing key as a default in the code can lead to security issues if accidentally used in live environments. Consider removing the default or retrieving it from environment variables or a secrets manager to reduce the risk of compromised private keys.
| OAuth2Scopes: []string{"auth:read", "auth:read"}, | ||
| SecuritySource: s.sdkConfiguration.Security, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify repeated OAuth2Scopes.
Each method includes []string{"auth:read", "auth:read"}. If this duplication is unintentional, consider adjusting the scope list to avoid confusion.
🏁 Script executed:
#!/bin/bash
# Search for repeated 'auth:read' entries in the file
rg --no-heading '"auth:read", "auth:read"'Length of output: 470
Action Required: Remove Duplicate OAuth2Scopes Entries
The output confirms that the "auth:read" scope is duplicated in every occurrence within pkg/client/v1.go (e.g., lines 35-36). Please verify if this repetition is intentional. If not, update the code to include a single instance per method to avoid potential confusion.
- File:
pkg/client/v1.go - Issue: Multiple instances of
[]string{"auth:read", "auth:read"}found across the file. - Recommendation: Retain only one
"auth:read"entry per method unless multiple entries were explicitly required. If multiple entries are necessary, consider adding a clarifying comment.
| func encodeFormData(fieldName string, w io.Writer, data interface{}) error { | ||
| requestType := reflect.TypeOf(data) | ||
| requestValType := reflect.ValueOf(data) | ||
|
|
||
| if requestType.Kind() == reflect.Pointer { | ||
| requestType = requestType.Elem() | ||
| requestValType = requestValType.Elem() | ||
| } | ||
|
|
||
| dataValues := url.Values{} | ||
|
|
||
| switch requestType.Kind() { | ||
| case reflect.Struct: | ||
| for i := 0; i < requestType.NumField(); i++ { | ||
| field := requestType.Field(i) | ||
| fieldType := field.Type | ||
| valType := requestValType.Field(i) | ||
|
|
||
| if isNil(fieldType, valType) { | ||
| continue | ||
| } | ||
|
|
||
| if fieldType.Kind() == reflect.Pointer { | ||
| fieldType = fieldType.Elem() | ||
| valType = valType.Elem() | ||
| } | ||
|
|
||
| tag := parseFormTag(field) | ||
| if tag.JSON { | ||
| data, err := MarshalJSON(valType.Interface(), field.Tag, true) | ||
| if err != nil { | ||
| return err | ||
| } | ||
| dataValues.Set(tag.Name, string(data)) | ||
| } else { | ||
| switch tag.Style { | ||
| // TODO: support other styles | ||
| case "form": | ||
| values := populateForm(tag.Name, tag.Explode, fieldType, valType, ",", func(sf reflect.StructField) string { | ||
| tag := parseFormTag(field) | ||
| if tag == nil { | ||
| return "" | ||
| } | ||
|
|
||
| return tag.Name | ||
| }) | ||
| for k, v := range values { | ||
| for _, vv := range v { | ||
| dataValues.Add(k, vv) | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| case reflect.Map: | ||
| for _, k := range requestValType.MapKeys() { | ||
| v := requestValType.MapIndex(k) | ||
| dataValues.Set(fmt.Sprintf("%v", k.Interface()), valToString(v.Interface())) | ||
| } | ||
| case reflect.Slice, reflect.Array: | ||
| for i := 0; i < requestValType.Len(); i++ { | ||
| v := requestValType.Index(i) | ||
| dataValues.Set(fieldName, valToString(v.Interface())) | ||
| } | ||
| } | ||
|
|
||
| if _, err := w.Write([]byte(dataValues.Encode())); err != nil { | ||
| return err | ||
| } | ||
|
|
||
| return nil | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve form data encoding coverage
Nested or complex structures may need specialized handling to avoid inconsistent encoding.
| func (c *clientCredentialsHook) doTokenRequest(ctx context.Context, credentials *credentials, scopes []string) (*session, error) { | ||
| values := url.Values{} | ||
| values.Set("grant_type", "client_credentials") | ||
| values.Set("client_id", credentials.ClientID) | ||
| values.Set("client_secret", credentials.ClientSecret) | ||
|
|
||
| if len(scopes) > 0 { | ||
| values.Set("scope", strings.Join(scopes, " ")) | ||
| } | ||
|
|
||
| tokenURL := credentials.TokenURL | ||
| u, err := url.Parse(tokenURL) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to parse token URL: %w", err) | ||
| } | ||
| if !u.IsAbs() { | ||
| tokenURL, err = url.JoinPath(c.baseURL, tokenURL) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to parse token URL: %w", err) | ||
| } | ||
| } | ||
|
|
||
| req, err := http.NewRequestWithContext(ctx, http.MethodPost, tokenURL, bytes.NewBufferString(values.Encode())) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to create token request: %w", err) | ||
| } | ||
|
|
||
| req.Header.Set("Content-Type", "application/x-www-form-urlencoded") | ||
|
|
||
| res, err := c.client.Do(req) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to send token request: %w", err) | ||
| } | ||
| defer res.Body.Close() | ||
|
|
||
| if res.StatusCode < 200 || res.StatusCode >= 300 { | ||
| body, _ := io.ReadAll(res.Body) | ||
| return nil, fmt.Errorf("unexpected status code: %d: %s", res.StatusCode, body) | ||
| } | ||
|
|
||
| var tokenRes tokenResponse | ||
| if err := json.NewDecoder(res.Body).Decode(&tokenRes); err != nil { | ||
| return nil, fmt.Errorf("failed to decode token response: %w", err) | ||
| } | ||
|
|
||
| if tokenRes.TokenType != "Bearer" { | ||
| return nil, fmt.Errorf("unexpected token type: %s", tokenRes.TokenType) | ||
| } | ||
|
|
||
| var expiresAt *int64 | ||
| if tokenRes.ExpiresIn != nil { | ||
| expiresAt = new(int64) | ||
| *expiresAt = time.Now().Unix() + *tokenRes.ExpiresIn | ||
| } | ||
|
|
||
| return &session{ | ||
| Credentials: credentials, | ||
| Token: tokenRes.AccessToken, | ||
| ExpiresAt: expiresAt, | ||
| Scopes: scopes, | ||
| }, nil | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add retries for transient failures
doTokenRequest does not handle transient errors or network hiccups. Consider implementing a retry policy to improve reliability.
2 participants
Also switch to go libs v2.
Fixes AUT-2