Skip to content
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

fix: Resolve list widget Error #37747

Open
wants to merge 3 commits into
base: release
Choose a base branch
from

Conversation

saharAdem
Copy link

@saharAdem saharAdem commented Nov 26, 2024

Description

This PR resolves an issue with the List widget caused by infinite auto height update loops. The child widgets of the List widget already have the isMetaWidget flag, which prevents auto height updates. However, the List widget itself did not have this flag, leading to the issue. This fix ensures that the isMetaWidget flag is also applied to the List widget, preventing the infinite update loop.

Fixes #37683

Automation

/ok-to-test tags=""

🔍 Cypress test results

Caution

If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication

Should the DevRel and Marketing teams inform users about this change?

  • Yes
  • No

Summary by CodeRabbit

  • Tests

    • Added a new Cypress test specification for the List widget's auto-height functionality
    • Verifies widget behavior during interactions and visibility changes
  • Bug Fixes

    • Improved logic for handling auto-height updates in List widgets
    • Prevented potential infinite loop scenarios during widget interactions

Copy link
Contributor

coderabbitai bot commented Nov 26, 2024

Walkthrough

This pull request addresses a bug in the List widget's auto-height update mechanism. The changes involve modifying the widget props handling to prevent an infinite loop error when interacting with the List widget. A new Cypress test specification is introduced to validate the widget's behavior, specifically testing the visibility and interaction of the List widget under specific conditions.

Changes

File Change Summary
app/client/cypress/e2e/Regression/ClientSide/BugTests/ListWidget_Bug37683_spec.ts Added new Cypress test for List widget interaction and visibility
app/client/src/widgets/withWidgetProps.tsx Modified auto-height dispatch logic to exclude List widget with meta widgets

Assessment against linked issues

Objective Addressed Explanation
List widget redirects to error page [#37683]
Prevent infinite loop during widget interaction

Possibly related PRs

Suggested labels

Bug, Release, Regressed, QA, ok-to-test, Query & JS Pod

Suggested reviewers

  • albinAppsmith
  • rahulbarwal

Poem

🎭 In the realm of widgets, a tale unfolds
Where List and Button dance, breaking old molds
A bug once lurked, causing loops so dire
Now fixed with code, extinguishing its fire! 🔧
Cypress tests sing, of triumph so bright 🌟


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bc3389b and 9f98421.

📒 Files selected for processing (1)
  • app/client/src/widgets/withWidgetProps.tsx (1 hunks)
🔇 Additional comments (1)
app/client/src/widgets/withWidgetProps.tsx (1)

304-305: LGTM! The fix prevents infinite auto-height updates for List widgets.

The additional condition correctly prevents auto-height updates when the widget is a List widget with meta widgets, addressing the infinite loop issue.

Let's verify the impact on other widgets that might rely on auto-height updates:

Would you like me to help generate additional test cases to verify this fix?

✅ Verification successful

✅ Auto-height changes are safely isolated to List widgets

The condition type === "LIST_WIDGET_V2" && widgetProps.hasMetaWidgets is specific to List widgets and won't affect auto-height behavior of other widgets. The change is safe to proceed with.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other widgets that might be affected by this change
# by looking for auto-height related patterns

echo "Searching for widgets using auto-height..."
rg -l "isAutoHeightEnabledForWidget|UPDATE_WIDGET_AUTO_HEIGHT" app/client/src/widgets

echo "Searching for potential height-related test failures..."
rg -l "height.*fail|fail.*height" app/client/cypress/e2e

Length of output: 1459


Script:

#!/bin/bash
# Check List widget's auto-height implementation
echo "Checking List widget auto-height implementation..."
ast-grep --pattern 'isAutoHeightEnabledForWidget($$$)' app/client/src/widgets/ListWidget/widget/index.tsx

echo "Checking for direct dependencies on List widget's auto-height..."
rg -l "ListWidget.*height|height.*ListWidget" --type ts --type tsx app/client/src/widgets

echo "Checking for any height-related issues in List widget tests..."
rg "height" -A 5 -B 5 app/client/src/widgets/ListWidget/widget/__tests__

Length of output: 779


Script:

#!/bin/bash
# Find List widget related files
echo "Locating List widget files..."
fd -t f "ListWidget.*\.(tsx?|spec|test)" app/client/src

echo "Checking for height-related code in List widget..."
rg "height" -t typescript -t javascriptreact -t typescriptreact $(fd -t f "ListWidget" app/client/src)

echo "Checking widget props usage..."
ast-grep --pattern 'type === "LIST_WIDGET_V2"' app/client/src

Length of output: 624

Finishing Touches

  • 📝 Generate Docstrings

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@saharAdem saharAdem changed the title rfix: fixing list widget Error fix: Resolve list widget Error Nov 26, 2024
@saharAdem
Copy link
Author

saharAdem commented Nov 26, 2024

@albinAppsmith @ankitakinger Could you please review the PR?

Copy link
Contributor

@rahulbarwal rahulbarwal left a comment

Choose a reason for hiding this comment

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

Thanks @saharAdem.
While we are reviewing this for any side effects. Can you please add some automation tests to ensure that we don't miss this again?

Copy link
Contributor

@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: 2

🧹 Outside diff range and nitpick comments (1)
app/client/cypress/e2e/Regression/ClientSide/BugTests/ListWidget_Bug37683_spec.ts (1)

12-15: Consider using relative positioning for widgets

The hardcoded x,y coordinates (300,600 and 600,600) might make the test brittle. Consider using relative positioning or grid-based placement if available.

-      cy.dragAndDropToCanvas("listwidgetv2", {
-        x: 300,
-        y: 600,
-      });
+      cy.dragAndDropToCanvas("listwidgetv2", { relative: true });

Also applies to: 22-25

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between a7bfac5 and bc3389b.

📒 Files selected for processing (1)
  • app/client/cypress/e2e/Regression/ClientSide/BugTests/ListWidget_Bug37683_spec.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/client/cypress/e2e/Regression/ClientSide/BugTests/ListWidget_Bug37683_spec.ts (1)

Pattern app/client/cypress/**/**.*: Review the following e2e test code written using the Cypress test library. Ensure that:

  • Follow best practices for Cypress code and e2e automation.
  • Avoid using cy.wait in code.
  • Avoid using cy.pause in code.
  • Avoid using agHelper.sleep().
  • Use locator variables for locators and do not use plain strings.
  • Use data-* attributes for selectors.
  • Avoid Xpaths, Attributes and CSS path.
  • Avoid selectors like .btn.submit or button[type=submit].
  • Perform logins via API with LoginFromAPI.
  • Perform logout via API with LogOutviaAPI.
  • Perform signup via API with SignupFromAPI.
  • Avoid using it.only.
  • Avoid using after and aftereach in test cases.
  • Use multiple assertions for expect statements.
  • Avoid using strings for assertions.
  • Do not use duplicate filenames even with different paths.
  • Avoid using agHelper.Sleep, this.Sleep in any file in code.
🔇 Additional comments (2)
app/client/cypress/e2e/Regression/ClientSide/BugTests/ListWidget_Bug37683_spec.ts (2)

38-39: LGTM: Assertions look good

The visibility assertions for both widgets are well-structured and follow best practices.


10-42: 🛠️ Refactor suggestion

Add cleanup after test

Consider adding cleanup to reset the application state after the test.

   describe("Bug 37683: List widget auto-height update infinite loop error", () => {
+    afterEach(() => {
+      // Clean up the canvas
+      agHelper.DeleteAllWidgets();
+    });
     it("The list widget height should not trigger an auto-height update", () => {

Likely invalid or redundant comment.

Comment on lines +33 to +35
cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
.eq(1)
.click({ force: true });
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Avoid force clicking without proper wait conditions

Using force: true might mask underlying issues. Consider waiting for the element to be properly interactable.

-      cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
-        .eq(1)
-        .click({ force: true });
+      cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
+        .eq(1)
+        .should('be.visible')
+        .and('be.enabled')
+        .click();
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
.eq(1)
.click({ force: true });
cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
.eq(1)
.should('be.visible')
.and('be.enabled')
.click();

cy.get(`${widgetSelector("List1")} ${containerWidgetSelector}`)
.eq(1)
.click({ force: true });
cy.wait(4000);
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

Replace cy.wait with proper assertions

Using arbitrary wait times can make tests flaky. Instead, wait for specific conditions.

-      cy.wait(4000);
+      cy.get(widgetSelector("List1")).should("not.be.visible");
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
cy.wait(4000);
cy.get(widgetSelector("List1")).should("not.be.visible");

Copy link

github-actions bot commented Dec 5, 2024

This PR has not seen activitiy for a while. It will be closed in 7 days unless further activity is detected.

@github-actions github-actions bot added the Stale label Dec 5, 2024
@saharAdem
Copy link
Author

Hi @rahulbarwal,
I added tests. Could you please check the PR?

@github-actions github-actions bot removed the Stale label Dec 6, 2024
@jacquesikot
Copy link
Contributor

@saharAdem I think the solution is incorrect here, we shouldn't add isMetaWidget to the default props as it would lead to isMetaWidget: true for every dropped list widget and this will have some implications.
I was checking out the issue and it seems if I have 2 buttons outside the list, use one to close and the other to open; it does not crashes so something else goes wrong when the list item is clicked and List1.setVisibility(false) is triggered.

Copy link
Contributor

@jacquesikot jacquesikot left a comment

Choose a reason for hiding this comment

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

I think the solution is incorrect here, we shouldn't add isMetaWidget to the default props as that would lead to isMetaWidget: true for every dropped list widget and this will have some implications

Copy link

This PR has not seen activitiy for a while. It will be closed in 7 days unless further activity is detected.

@github-actions github-actions bot added the Stale label Dec 19, 2024
@saharAdem
Copy link
Author

I believe the issue is caused by an infinite loop of auto-height updates. I will investigate further. However, this has occurred multiple times when using the list widget.

@github-actions github-actions bot removed the Stale label Dec 27, 2024
Copy link

github-actions bot commented Jan 5, 2025

This PR has not seen activitiy for a while. It will be closed in 7 days unless further activity is detected.

@github-actions github-actions bot added the Stale label Jan 5, 2025
@saharAdem saharAdem requested a review from a team as a code owner January 9, 2025 11:06
@saharAdem
Copy link
Author

saharAdem commented Jan 9, 2025

@saharAdem I think the solution is incorrect here, we shouldn't add isMetaWidget to the default props as it would lead to isMetaWidget: true for every dropped list widget and this will have some implications. I was checking out the issue and it seems if I have 2 buttons outside the list, use one to close and the other to open; it does not crashes so something else goes wrong when the list item is clicked and List1.setVisibility(false) is triggered.

@jacquesikot Thanks for your explanation. The issue occurs due to auto-height updates in the list widget, which causes an infinite loop.

Any list widget should be prevented from auto height updates. The inner widgets of the list widget are already excluded from auto-height updates using the isMetaWidget property that added in the MetaWidgetGenerator.ts file
. as outlined here

         if (shouldCollapseWidgetInViewOrPreviewMode) {
        // This flag (isMetaWidget) is used to prevent the Auto height saga from updating
        // the List widget Child Widgets. Auto height is disabled in the List widget and
        // this flag serves as a way to avoid any unintended changes to the child widget's height.
        if (
          widgetProps.bottomRow !== widgetProps.topRow &&
          !widgetProps.isMetaWidget
        ) {
          dispatch({
            type: ReduxActionTypes.UPDATE_WIDGET_AUTO_HEIGHT,
            payload: {
              widgetId: props.widgetId,
              height: 0,
            },
          });
        }

Since the existing code and logic in the MetaWidgetGenerator.ts are based on applying isMetaWidget to the list widget's child widgets, and to avoid unintended consequences, auto-height updates for the list widget itself should also be disabled. I have added some failing use cases to the issue 37683 which you can review there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: List widget redirects to error page
3 participants