[Security Solution]Log for deleted Value list file retains on the Upload Value List table.

[ghost]

Description:
Log for deleted Value list file retains on the Upload Value List table.

Build Details:
Version: 7.13.0 BC5
Build: 40845
Commit: ffb66d3
Artifact link: https://staging.elastic.co/7.13.0-40842f6d/summary-7.13.0.html

Browser Details:
All

Preconditions:

• Kibana Environment should exist.
• Endpoint security and Elastic Agent should be installed
• Detection alters should be generated.
• Uploaded Files should exist in the Value list table

Steps to Reproduce:

1. Navigate to Detection tab under Security App.
2. Click on 'Manage Detection Rules' link.
3. Click 'Upload Value list' button.
4. Click on 'Remove Value List' icon and Notice that a table loader runs but file log is still present in the Table.
5. Now, again Click on 'Remove Value List' icon and 'Remove value list' pop-up will be displayed.
6. Click on 'Remove value list' button and observe that deleted file still appears in the table.

Impacted Test case:
N/A

Actual Result:
Log for recently deleted Value list file retains in the Upload Value List table.

Expected Result:
Log for recently deleted Value list file should immediately be removed from the Upload Value List table and the table list should be refreshed.

What's not working:

• NA

What's working:

• This issue is occurring on 'Upload Value List' table only.

Work Around

• Refresh the browser or click on any other link to refresh the page.

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[ghost]

@manishgupta-qasource Please review!

[manishgupta-qasource]

Reviewed & assigned to @MadameSheema

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[MadameSheema]

@mandeepkaur-qasource can you please confirm if after refreshing the browser the list is still present? Thank you :)

[MadameSheema]

@mandeepkaur-qasource can you please also check if this bug is present on 7.12.1? Thanks :)

[ghost]

@mandeepkaur-qasource can you please confirm if after refreshing the browser the list is still present? Thank you :)

Refreshed the Browser and found that the list is not present.

Thanks!!

[ghost]

@mandeepkaur-qasource can you please also check if this bug is present on 7.12.1? Thanks :)

Cross checked this on 7.12.1 and found that it's working fine there.

Build Details:
Version: 7.12.1
Build: 39457
Commit: abb04c5

[spong]

++ @mandeepkaur-qasource, just debugged this a little and verified this is a race condition with the SO refresh. When it occurs you can see that both the delete request was successful, and the subsequent _find request from refreshing the table that the entity is still returned.

I'm not sure if the SO refresh is configurable here, but some other options to fix would be a short timeout post-successful delete (and just keep the delete loader going for a few hundred ms more), or a heavier polling action post-successful delete. I suggest we keep this issue open and dig a little deeper to see if a configurable refresh is available, and if not implement one of the lighter-weight methods to prevent users from getting in this error state.

[ghost]

++ @mandeepkaur-qasource, just debugged this a little and verified this is a race condition with the SO refresh. When it occurs you can see that both the delete request was successful, and the subsequent _find request from refreshing the table that the entity is still returned.

I'm not sure if the SO refresh is configurable here, but some other options to fix would be a short timeout post-successful delete (and just keep the delete loader going for a few hundred ms more), or a heavier polling action post-successful delete. I suggest we keep this issue open and dig a little deeper to see if a configurable refresh is available, and if not implement one of the lighter-weight methods to prevent users from getting in this error state.

Hi @spong

We have validated this ticket on 7.12.1 build & compared the results with 7.13.0 build. Below are the Observations:

7.12.1:

Build Details:
Version: 7.12.1
Build: 39457
Commit: abb04c5
Artifact link: https://staging.elastic.co/7.12.1-4d63d11a/summary-7.12.1.html

Observation:
After deleting the file, The "data:" attribute contains no information regarding deleted file.

** 7.13.0:**

Build Details:
Version: 7.13.0 BC9
Build: 40865
Commit: 9863e88
Artifact link: https://staging.elastic.co/7.13.0-c04b1ebc/summary-7.13.0.html

Observation:
The "data:" attribute still contains the information regarding the table data for deleted file.

Thanks!!

[ghost]

Hi @MadameSheema ,

We have validated this ticket on 7.15.0-SNAPSHOT build and found that issue is Still Occurring.

Build Details:

Version:7.15.0 SNAPSHOT
Commit:aa12d107c38c5cda96fc32bcd1f8226df172826a
Build:43370

Screenshot:

Delete_value_list.mp4

Thanks.

[peluja1012]

Fixed by this PR #111838. @mandeepkaur-qasource Could you please retest in the latest master build?

[ghost]

Hi @peluja1012,

We have validated this issue on the latest 8.0.0 Snapshot build and found that the issue has been Fixed as Log for recently deleted file immediately gets removed from the "Upload Value List" table and the table list gets refreshed. Moreover, we have also validated this defect by deleting files from different pagination links under 'Upload Value List' table and found that after deleting any uploaded file from any pagination link, the user correctly gets navigated to initial/first Value list page.

Please find the below observation:
Screen -Cast:

Build Details:
Version: 8.0.0 Snapshot
Build: 46419
Commit: 525d3a5
Artifact link: https://artifacts-api.elastic.co/v1/search/8.0.0-SNAPSHOT

Hence, we are closing this issue.
Thanks!!