Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: [email protected]
  Slack: https://s.apache.org/airflow-slack

@vishakha1411 Thanks for the PR. I will review soon

I fixed the failing errors and removed redundant cross-browser compatibility tests. Since Playwright already executes the full test suite across all supported browsers, these tests were unnecessary. Please check now.

I fixed the failing errors and removed redundant cross-browser compatibility tests. Since Playwright already executes the full test suite across all supported browsers, these tests were unnecessary. Please check now.

Thanks @vishakha1411 I will review soon

@vatsrahul1001 I noticed some static checks failed. I tried to fix them by explicitly handling nullable string values, changing null to undefined for consistency, and fixing naming conventions. Hope it works now, please check!

@vishakha1411 Great first PR! there are several alignment issues with our existing patterns that need to be addressed specifically in pagination and filter/search tests. I suggest to you look at how these are implemented for other pages.

@vatsrahul1001 I have made the changes you pointed out.

Key Changes

• Removed all waitForTimeout calls - replaced with expect.poll() and explicit element waits
• Removed console logs
• Improved pagination test - formatted according to already existing tests
• Fixed filtering tests

@vatsrahul1001 @choo121600 I noticed that a few CRUD tests are failing on Chromium in CI, while the same tests pass on Firefox and WebKit. All tests are also passing locally for all browsers.
It seems like CI is sometimes unable to locate elements within the timeout in Chromium. Could you please suggest the best way to handle this? Would increasing timeouts be acceptable here, or is there a preferred approach for this?
Also, please let me know if any other changes are required in the code.

@vatsrahul1001 @choo121600 I noticed that a few CRUD tests are failing on Chromium in CI, while the same tests pass on Firefox and WebKit. All tests are also passing locally for all browsers. It seems like CI is sometimes unable to locate elements within the timeout in Chromium. Could you please suggest the best way to handle this? Would increasing timeouts be acceptable here, or is there a preferred approach for this? Also, please let me know if any other changes are required in the code.

@vishakha1411 As per the stacktrace from failure I see even after clicking on edit button edit form is not visible as per failure screenshot

  131 |     await expect(editButton).toBeVisible({ timeout: 5000 });
  132 |     await editButton.click();
> 133 |     await expect(this.connectionIdInput).toBeVisible({ timeout: 3000 });
      |                                          ^
  134 |   }

For debugging purposes, always try to look at the failure report. You can download the report from upload result steps.

There could be two issues here: either the edit button is not getting clicked correctly, or it's taking time to open the edit button. Yes, you can try increasing the timeout, and also confirm if the edit button is getting clicked correctly or not.

As you mentioned, it works locally fine, but I still suggest trying running test in UI mode, you can --ui-mode in breeze test command arg. It helps a lot in debugging

@vishakha1411 How are we progressing on this?

@vishakha1411 How are we progressing on this?

@vatsrahul1001 I made a few fixes to address the flaky tests. All the tests pass now. Please review and let me know if any changes are required.

@vishakha1411 How are we progressing on this?

@vatsrahul1001 I made a few fixes to address the flaky tests. All the tests pass now. Please review and let me know if any changes are required.

Thanks @vishakha1411 I will review soon!

@vishakha1411 can you look at failing tests? Also lets remove pagination and sorting test as discussed in comment. We will cover all testing behaviour in react unit tests

@vatsrahul1001 I have fixed the failing tests and have removed the pagination and sorting tests as suggested. All the tests pass now.
PTAL. Thanks.

Nice!.