fix(cmd): move file read from newInvokeConfig to runInvoke#3847
fix(cmd): move file read from newInvokeConfig to runInvoke#3847Elvand-Lie wants to merge 1 commit into
Conversation
|
Hi @Elvand-Lie. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3847 +/- ##
=======================================
Coverage 53.44% 53.44%
=======================================
Files 200 200
Lines 23450 23406 -44
=======================================
- Hits 12533 12510 -23
+ Misses 9662 9648 -14
+ Partials 1255 1248 -7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6087745 to
7fb6180
Compare
|
The removed
I suspect the first |
|
/assign |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Elvand-Lie The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
e08e880 to
066d374
Compare
ad5d837 to
a7f0756
Compare
|
@gauron99 Right. Since this was meant to be a cleanup, I saw the two os.ReadFile blocks and assumed the second one in runInvoke() was redundant because cfg.Data was already populated. I didn't account for the interactive --confirm prompts mutating cfg.File between the two reads, meaning the first read pulls stale data. My bad. I've pushed a fix:
|
There was a problem hiding this comment.
Pull request overview
Removes redundant disk I/O when func invoke --file ... is used by ensuring the file contents are only read once and used as the invocation payload.
Changes:
- Moves
--filereading logic so the invocation message data is populated from a single read. - Removes the previous duplicated/now-unnecessary file-read logic.
- Adds unit tests covering
--filesuccess and missing-file error behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
cmd/invoke.go |
Refactors when/where --file is read to avoid redundant reads and feed cfg.Data into the invoke message. |
cmd/invoke_test.go |
Adds tests validating --file payload handling and error reporting for missing files. |
Comments suppressed due to low confidence (1)
cmd/invoke.go:287
- Reading the file in runInvoke means cfg.Data is still the flag-provided "data" value during newInvokeConfig(). In
--confirmnon-interactive mode, the command printsData:before this read happens, so the confirmation output can be misleading when--fileis set. Consider loading the file into cfg.Data inside newInvokeConfig after any interactive prompts have completed (and before printing/returning), and then avoid mutating cfg later in runInvoke.
switch strings.ToLower(cfg.Format) {
case "cloudevent", "cloudevents":
cfg.Format = "cloudevent"
}
// if not in confirm/prompting mode, the cfg structure is complete.
if !cfg.Confirm {
return
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The os.ReadFile in newInvokeConfig() runs before --confirm prompts, so if a user changes the file path during interactive prompts, the old file contents get sent. Move the read to runInvoke() after config is finalized and before client initialization for fail-fast behavior. Add TestInvoke_FileFlag and TestInvoke_FileFlagNonExistent tests with sync.Mutex for proper cross-goroutine synchronization.
a7f0756 to
4bce48d
Compare
Fixes #3846
Problem
When
--fileis passed tofunc invoke, the file contents were read from disk twice:newInvokeConfig()— reads file intocfg.DatarunInvoke()— reads the same file again intom.DataThe first read in
newInvokeConfig()is problematic because it occurs before the--confirminteractive prompts. If the user changes the file path during these prompts, the original file data has already been loaded, causing stale data to be sent.Changes
This PR removes the early file read and ensures the file is read only once, at the correct time:
os.ReadFileblock fromnewInvokeConfig().runInvoke(), executing it after the configuration is finalized and immediately before client initialization for fail-fast behavior.TestInvoke_FileFlagandTestInvoke_FileFlagNonExistentwithsync.Mutexsynchronization to explicitly test file-based invocation and error handling.Testing
TestInvoke_FileFlag— Verifies that providing a valid file correctly reads and sends its contents to the mock server.TestInvoke_FileFlagNonExistent— Verifies that providing a non-existent file path immediately returns the appropriate error.