-
Notifications
You must be signed in to change notification settings - Fork 0
Refactor/calypr clients #26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: bwalsh <47808+bwalsh@users.noreply.github.com>
Co-authored-by: bwalsh <47808+bwalsh@users.noreply.github.com>
Co-authored-by: bwalsh <47808+bwalsh@users.noreply.github.com>
Address PR #19 review comments: naming, test coverage, and documentation
| fur.Progress = noopProgress | ||
|
|
||
| logger.Println("\t" + localFilePath + " → GUID " + obj.ObjectID) | ||
| logger.Println("\t" + localFilePath + " → GUID " + obj.GUID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use fmt.Errorf and fmt.Sprintf for better performance and readability.
|
@matthewpeterkort This is a big PR. Trying to understand all of it. Can you give me some starting points? eg New code vs moved code? |
Summary slog handler✅ This branch centralizes progress reporting in context.Context and introduces new slog handler plumbing (including a progress-forwarding handler) to integrate log messages with progress callbacks. issues❌ Log source attribution is still incorrect for wrapper methods. Failed/Succeeded call their *Context counterparts, which then call logWithSkip(..., 3, ...). That skip value points the source to the wrapper method (or deeper) instead of the original caller, undermining the stated goal of accurate source attribution. Consider increasing the skip for these wrapper paths (e.g., Failed/Succeeded should pass a higher skip, or logWithSkip should accept an extra skip delta for wrappers). https://github.com/calypr/data-client/blob/refactor/calypr-clients/logs/tee_logger.go#L56-L204 suggestions❓ The progress handler currently forwards only r.Message (and omits level/attrs). If progress consumers need richer diagnostics, consider including r.Level and relevant attributes in the emitted ProgressEvent payload (or serialize the record). https://github.com/calypr/data-client/blob/refactor/calypr-clients/logs/handler.go#L27-L41 |
Summary new/updated tests🔍 What I looked atdownload/transfer_test.go — progress callback usage updated to come from context.Context, and fake client updated to satisfy the new Sower() interface requirement. upload/multipart_test.go — progress callback now passed via context, and OID explicitly set to match new progress plumbing; fake client updated for Sower() interface. logs/logger_test.go — base logger test updated to use slog.Logger to match the new WithBaseLogger type signature. ⚖️ Findings✅ No issues found with the new test updates. The changes align with the new context-based progress plumbing and updated logger configuration: The download progress tests now correctly attach the callback via context, consistent with the production code’s common.WithProgress usage. The multipart upload test now sets both progress callback and OID in context, matching the new flow used in multipart upload progress events. Logger tests correctly reflect the new *slog.Logger type for WithBaseLogger. |
the sower client code was taken from Forge and moved in here. The indexd client code was taken from git-drs and moved in here. The fence client code was ripped out of the existing ./upload and ./download business logic directories and rewritten as a dedicated client. See summary at top |
AI generated PR changes summary. Read it over it is quite accurate for what has changed.
Technical Changelog: Local
refactorvs RemotedevelopThis document details the technical differences between your current local branch (
refactor/calypr-clients) and the remotedevelopbranch.1. Architectural Overhaul: Client Modularization
The monolithic
g3client.g3clientOrchestrator:g3client.Gen3Interfaceandg3client.Gen3Client.g3.DeleteRecord), the client now exposes sub-clients:g3.Fence().DeleteRecord(...)g3.Indexd().GetObject(...)g3.Sower().DispatchJob(...)Gen3Clientnow injectsRequestInterface,FenceInterface, etc., making unit testing with mocks significantly easier.2. System-Wide Logging Migration (
log/slog)The entire logging subsystem has been rewritten to use Go's standard structured logging library (
log/slog).logs/factory.go:io.Writerbased logging replaced withslog.Handlerchains.NewProgressHandlerwraps the root handler to coordinate with progress bars.New()now returns*Gen3Logger(wrapping*slog.Logger) instead of the custom*TeeLogger.logger.Printfreplaced withlogger.InfoContext(ctx, ...)orlogger.WarnContext(ctx, ...).3. Configuration & Authentication Logic
Refined validation logic in
conf/validate.goto be more granular and informative.IsValidbroken down intoIsTokenValidandIsCredentialValid.IsCredentialValidchecks bothAccessTokenandAPIKeyindependently.access_tokenis invalid butapi_keyis valid (triggering refresh logic elsewhere).Loggerwhen tokens are nearing expiration (previously just returned a formatted string).4. Breaking API & Field Renames
Several core data structures have been standardized, causing breaking changes for consumers of these structs.
Upload Package (
upload/)RetryObject&FileUploadRequestObject:FilePath→ Renamed toSourcePath(clarifies intent vs destination).Filename→ Renamed toObjectKey(standard S3/object storage terminology).Download Package (
download/)ManifestObject:ObjectID→ Renamed toGUID(standard Gen3 terminology).downloader.go:AskForConfirmationnow returns an error on user abortion instead of callinglogger.Fataldirectly, allowing better cleanup/exit handling.WarnContextinstead of standard print.5. New Features
sower/): First-class support for dispatching and monitoring Sower jobs (DispatchJob,Status,Output).g3client.EnsureValidCredentialadded to centrally handle the "check validity -> if invalid but API key good -> refresh -> save" loop.6. Project Structure Moves