Skip to content

Conversation

@aufi
Copy link
Member

@aufi aufi commented Sep 30, 2025

Resolves: https://issues.redhat.com/browse/MTA-6029
Resolves: #2654

When uploading multiple custom rules in analyzer wizard, only last one was corectly processed for it s rules, updating code to make sure each uploaded file processed.

Used claude code to assist with this change.

Summary by CodeRabbit

  • New Features

    • Rule files now begin processing immediately after selection with initial progress/status visible.
    • Each file carries its own per-file context through the upload lifecycle for clearer handling and callbacks.
  • Bug Fixes

    • Upload progress and status updates are more consistent and visible.
    • Success and error callbacks reliably map to the correct file, preventing stale state and improving error attribution.

When uploading multiple custom rules in analyzer wizard, only last one
was corectly processed for it s rules, updating code to make sure each
uploaded file processed.

Used claude code to help with this change.

Signed-off-by: Marek Aufart <[email protected]>
@coderabbitai
Copy link

coderabbitai bot commented Sep 30, 2025

Walkthrough

Per-file UploadFile contexts are created and stored internally when files begin uploading; these contexts are threaded through upload calls and delivered to onSuccess/onError callbacks. useFileUploader and uploadFile signatures were extended to accept an optional ruleFileContext, and the internal map clears contexts after callback invocation.

Changes

Cohort / File(s) Summary of Changes
Hook API & per-file context propagation
client/src/app/components/CustomRuleFilesUpload.tsx
Extended useFileUploader onSuccess/onError signatures to include an optional ruleFileContext?: UploadFile. Extended uploadFile to accept ruleFileContext?: UploadFile. Added internal fileContextRef map to store/retrieve per-file UploadFile contexts and clear them after use.
Deferred upload initiation & optimistic state
client/src/app/components/CustomRuleFilesUpload.tsx
Reworked incoming-file processing to defer execution (via setTimeout) and iterate incomingFiles, calling readVerifyAndUploadFile(ruleFile, file) per file. On start, files are given optimistic state (uploadProgress=20, status="validated") and then uploaded with the per-file context.
Upload lifecycle & callback wiring
client/src/app/components/CustomRuleFilesUpload.tsx
createRuleFile / uploadTaskgroupFile and upload flow now forward the stored per-file context to onSuccess/onError. Callbacks receive optional ruleFileContext, and the hook removes the context entry from fileContextRef after invoking callbacks.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User
  participant UI as CustomRuleFilesUpload
  participant Timer as setTimeout
  participant Verifier as readVerifyAndUploadFile
  participant Hook as useFileUploader
  participant API as createRuleFile / uploadTaskgroupFile

  User->>UI: Add rule files
  UI->>Timer: Defer processing incomingFiles
  Timer-->>UI: Iterate files
  loop For each file
    UI->>Verifier: readVerifyAndUploadFile(ruleFile, file)
    Verifier->>Hook: uploadFile(file, taskgroupId?, ruleFileContext)
    Hook->>Hook: fileContextRef[file.name] = ruleFileContext
    Hook->>API: createRuleFile / uploadTaskgroupFile (uses stored context)
    alt Upload success
      API-->>Hook: success + hubFile
      Hook->>Hook: ctx = retrieve & delete fileContextRef[file.name]
      Hook-->>UI: onSuccess(file, hubFile, ctx)
      UI->>UI: update ruleFile (uploadProgress/status)
    else Upload error
      API-->>Hook: error (AxiosError)
      Hook->>Hook: ctx = retrieve & delete fileContextRef[file.name]
      Hook-->>UI: onError(error, file, ctx)
      UI->>UI: update ruleFile (loadError/status)
    end
  end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

I stash a context, hop, then start each file,
I pause the crowd, then process them with style.
Success gets a wink, errors find a map,
I clear my pouch, tidy every gap.
A rabbit’s upload dance—swift, neat, and agile. 🐰✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (4 passed)
Check name Status Explanation
Title Check ✅ Passed The pull request title uses the correct emoji alias prefix and concisely summarizes the primary change, namely fixing the upload of multiple custom rule files, making its purpose immediately clear to reviewers.
Linked Issues Check ✅ Passed The implementation extends the file upload hook to propagate a per-file context and invoke callbacks for each file independently, directly addressing the root cause where only the last file was processed and fulfilling the objectives of issue #2654 by ensuring every uploaded custom rule file is parsed and registered.
Out of Scope Changes Check ✅ Passed All modifications are strictly within the custom rules upload component and its file uploader hook, focusing on per-file context tracking and callback updates, with no unrelated code or configuration changes, so the pull request remains fully in scope.
Description Check ✅ Passed The pull request description lists the linked issue references and provides a brief summary of the problem and the code change, satisfying the repository’s minimal template requirements and giving reviewers enough context to understand what was fixed.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 516265f and 870f5c3.

📒 Files selected for processing (1)
  • client/src/app/components/CustomRuleFilesUpload.tsx (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
client/src/app/components/CustomRuleFilesUpload.tsx (1)
client/src/app/utils/utils.ts (1)
  • getAxiosErrorMessage (10-16)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: unit-test
  • GitHub Check: build-and-upload-for-global-ci

@aufi
Copy link
Member Author

aufi commented Sep 30, 2025

@aufi aufi marked this pull request as draft September 30, 2025 13:12
@aufi aufi marked this pull request as ready for review September 30, 2025 13:41
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
client/src/app/components/CustomRuleFilesUpload.tsx (1)

153-159: Simplify: Remove redundant updatedRuleFile construction.

Lines 153-158 duplicate the state update already performed on lines 144-149. Both create an object with uploadProgress: 20, status: "validated", and contents: fileContents.

Apply this diff to eliminate the duplication and directly pass the updated ruleFile:

   onChangeRuleFile({
     ...ruleFile,
     uploadProgress: 20,
     status: "validated",
     contents: fileContents,
   });

   // Upload the file to hub!
   // TODO: Provide an onUploadProgress handler so the actual upload can be tracked from 20% to 100%
-  const updatedRuleFile = {
-    ...ruleFile,
-    uploadProgress: 20,
-    status: "validated" as const,
-    contents: fileContents,
-  };
-  uploadFile(file, taskgroupId, updatedRuleFile);
+  uploadFile(file, taskgroupId, {
+    ...ruleFile,
+    uploadProgress: 20,
+    status: "validated",
+    contents: fileContents,
+  });
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 870f5c3 and c89e34b.

📒 Files selected for processing (1)
  • client/src/app/components/CustomRuleFilesUpload.tsx (4 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
client/src/app/components/CustomRuleFilesUpload.tsx (4)
client/src/app/utils/utils.ts (1)
  • getAxiosErrorMessage (10-16)
client/src/app/api/models.ts (2)
  • HubFile (815-819)
  • UploadFile (602-611)
client/src/app/queries/targets.ts (1)
  • useCreateFileMutation (103-124)
client/src/app/queries/taskgroups.ts (1)
  • useUploadTaskgroupFileMutation (54-73)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: run-global-ci / e2e-ui-integration-tests
🔇 Additional comments (3)
client/src/app/components/CustomRuleFilesUpload.tsx (3)

170-193: Excellent fix: Context propagation eliminates fragile state lookups.

This implementation directly addresses the critical issues from past reviews by:

  1. Passing ruleFileContext through the upload chain instead of using setTimeout + ruleFileByName lookups that could retrieve stale state.
  2. Preserving all file properties (including contents) via the spread operator, ensuring success/error handlers update the correct file with complete data.
  3. Safe handling via if (ruleFileContext) guards that prevent crashes if context is missing.

The pattern of storing context in a Map (see lines 276-313) and retrieving it in callbacks ensures state updates reference the correct file snapshot without timing dependencies.


268-303: Clean context management pattern.

The Map-based context storage correctly:

  1. Associates each file with its upload context using file.name as the key (line 312).
  2. Retrieves context in callbacks (lines 281, 286, 294, 299) without relying on timing-sensitive state lookups.
  3. Cleans up after use (lines 283, 288, 296, 301) to prevent memory leaks.

The filename uniqueness assumption is safe because setupFilesToUpload (lines 68-78) removes files with duplicate names before adding new ones, preventing key collisions.


305-324: Backward-compatible signature extension.

The optional ruleFileContext parameter (line 308) cleanly extends the uploadFile API without breaking existing callers. Context storage (lines 311-313) is isolated from the core upload logic, maintaining separation of concerns.

@sjd78 sjd78 added this to the v0.8.1 milestone Oct 1, 2025
@sjd78 sjd78 added the cherry-pick/release-0.8 This PR should be cherry-picked to release-0.8 branch label Oct 1, 2025
Copy link
Member

@sjd78 sjd78 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe some extra code in there that doesn't need to be there, and one style change, but it did work in my testing.

@sjd78 sjd78 removed this from the v0.8.1 milestone Oct 9, 2025
aufi and others added 2 commits October 10, 2025 09:35
Co-authored-by: Scott Dickerson <[email protected]>
Signed-off-by: Marek Aufart <[email protected]>
Signed-off-by: Marek Aufart <[email protected]>
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
client/src/app/components/CustomRuleFilesUpload.tsx (1)

151-175: Defensive if (ruleFileContext) guards may silently skip updates.

Both callbacks skip the onChangeRuleFile update when ruleFileContext is undefined. While this prevents crashes, it silently hides missing context, which could mask bugs if uploadFile is ever called without providing the context.

Consider adding a warning log or comment explaining this defensive behavior, especially since the current flow (line 141) always provides the context.

Example:

-    (file, hubFile, ruleFileContext) => {
-      if (ruleFileContext) {
+    (file, hubFile, ruleFileContext) => {
+      if (!ruleFileContext) {
+        console.warn(`Missing context for file ${file.name}; skipping state update`);
+        return;
+      }
+      {
         onChangeRuleFile({
           ...ruleFileContext,
           fileId: hubFile?.id,
           uploadProgress: 100,
           status: "uploaded",
         });
       }
     },
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7bf13b4 and ac367e2.

📒 Files selected for processing (1)
  • client/src/app/components/CustomRuleFilesUpload.tsx (3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
client/src/app/components/CustomRuleFilesUpload.tsx (4)
client/src/app/api/models.ts (2)
  • UploadFile (602-611)
  • HubFile (815-819)
client/src/app/utils/utils.ts (1)
  • getAxiosErrorMessage (10-16)
client/src/app/queries/targets.ts (1)
  • useCreateFileMutation (103-124)
client/src/app/queries/taskgroups.ts (1)
  • useUploadTaskgroupFileMutation (54-73)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: unit-test
  • GitHub Check: build-and-upload-for-global-ci
🔇 Additional comments (2)
client/src/app/components/CustomRuleFilesUpload.tsx (2)

132-141: LGTM! Clean context propagation.

The flow correctly creates the complete updatedRuleFile context (including contents), updates the parent state, then passes that context to uploadFile. This ensures callbacks receive the full per-file context rather than relying on stale state lookups.


250-311: LGTM! Solid per-file context implementation.

The Map-based context storage correctly preserves per-file state through async callbacks, fixing the original issue where only the last file was processed. Key strengths:

  • Uses file.name as the Map key (safe given setupFilesToUpload removes duplicates before adding)
  • Retrieves and deletes context in both success and error paths (good memory hygiene)
  • Consistent pattern for both createRuleFile and uploadTaskgroupFile flows

Minor note: If an upload hangs indefinitely (callbacks never fire), the context remains in the Map. This is unlikely in practice and the Map is scoped to component lifecycle, so impact is minimal.

@aufi aufi requested a review from sjd78 October 15, 2025 11:53
@aufi
Copy link
Member Author

aufi commented Oct 15, 2025

PR was updated removing not needed code, local test works well for me, asking for re-review @sjd78, thanks!

Copy link
Member

@sjd78 sjd78 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good and my local testing works out great.

@sjd78 sjd78 merged commit e0773e0 into konveyor:main Oct 21, 2025
11 checks passed
github-actions bot pushed a commit that referenced this pull request Oct 21, 2025
Resolves: https://issues.redhat.com/browse/MTA-6029
Resolves: #2654

When uploading multiple custom rules in analyzer wizard, only last one
was corectly processed for it s rules, updating code to make sure each
uploaded file processed.

Used claude code to assist with this change.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Rule files now begin processing immediately after selection with
initial progress/status visible.
* Each file carries its own per-file context through the upload
lifecycle for clearer handling and callbacks.

* **Bug Fixes**
  * Upload progress and status updates are more consistent and visible.
* Success and error callbacks reliably map to the correct file,
preventing stale state and improving error attribution.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Marek Aufart <[email protected]>
Signed-off-by: Cherry Picker <[email protected]>
sjd78 pushed a commit that referenced this pull request Oct 22, 2025
Resolves: https://issues.redhat.com/browse/MTA-6029
Resolves: #2654

When uploading multiple custom rules in analyzer wizard, only last one
was corectly processed for it s rules, updating code to make sure each
uploaded file processed.

Used claude code to assist with this change.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Rule files now begin processing immediately after selection with
initial progress/status visible.
* Each file carries its own per-file context through the upload
lifecycle for clearer handling and callbacks.

* **Bug Fixes**
  * Upload progress and status updates are more consistent and visible.
* Success and error callbacks reliably map to the correct file,
preventing stale state and improving error attribution.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Marek Aufart <[email protected]>
Signed-off-by: Cherry Picker <[email protected]>
Co-authored-by: Marek Aufart <[email protected]>
sshveta pushed a commit to sshveta/tackle2-ui that referenced this pull request Oct 31, 2025
Resolves: https://issues.redhat.com/browse/MTA-6029
Resolves: konveyor#2654

When uploading multiple custom rules in analyzer wizard, only last one
was corectly processed for it s rules, updating code to make sure each
uploaded file processed.

Used claude code to assist with this change.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Rule files now begin processing immediately after selection with
initial progress/status visible.
* Each file carries its own per-file context through the upload
lifecycle for clearer handling and callbacks.

* **Bug Fixes**
  * Upload progress and status updates are more consistent and visible.
* Success and error callbacks reliably map to the correct file,
preventing stale state and improving error attribution.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Marek Aufart <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherry-pick/release-0.8 This PR should be cherry-picked to release-0.8 branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Konveyor does not detect rules when multiple ones are uploaded at once

2 participants