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

Spark 3.5: Fix the setting of equalAuthorities in RemoveOrphanFilesProcedure #10334

Merged
merged 1 commit into from
May 16, 2024

Conversation

hantangwangd
Copy link
Contributor

This PR correct the setting of procedure parameter equalAuthorities for RemoveOrphanFilesProcedure. Previously it seems to be wrongly set.

@github-actions github-actions bot added the spark label May 14, 2024
@nastra
Copy link
Contributor

nastra commented May 14, 2024

change LGTM, could you please add a test to TestRemoveOrphanFilesProcedure or TestRemoveOrphanFilesAction?

@hantangwangd
Copy link
Contributor Author

@nastra Sure! The test case for equal authorities has been added to TestRemoveOrphanFilesProcedure.testRemoveOrphanFilesProcedureWithPrefixMode(), please take a look when available, thanks.

@@ -647,19 +648,33 @@ public void testRemoveOrphanFilesProcedureWithPrefixMode()
"CALL %s.system.remove_orphan_files("
+ "table => '%s',"
+ "equal_schemes => map('file1', 'file'),"
+ "equal_authorities => map('localhost', '%s'),"
Copy link
Contributor

Choose a reason for hiding this comment

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

rather than modifying an existing test I think we should just have a simple & separate test method that reproduces the underlying issue

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion, that makes sense. The test logic has been moved to a separate method testRemoveOrphanFilesProcedureWithEqualAuthorities().


// Drop table in afterEach has purge and fails due to invalid scheme "file1" used in this test
// Dropping the table here
sql("DROP TABLE %s", tableName);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think the comment applies here, so we can remove dropping the table here, since it will be dropped in afterEach

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing out that. Sorry for overlook the incorrect comment here, but I notice that it has the same problem when executing drop table purge in afterEach, since the file path is not correct. So I fix the comment and keep the dropping table statement here, do you think this is suitable?

Copy link
Contributor

Choose a reason for hiding this comment

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

I haven't seen any issue when running the full test class locally, so I'm surprised it failed for you. Could you please remove this drop and we'll see if it fails/passes on CI?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It doesn't fail, but print a lot of error log, the same as test method testRemoveOrphanFilesProcedureWithPrefixMode()

Copy link
Contributor

Choose a reason for hiding this comment

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

ok thanks for clarifying. It seems testRemoveOrphanFilesProcedureWithPrefixMode() also doesn't explicitly fail but logs a lot of errors in the log when the table isn't dropped within the method itself. That being said, it's ok to keep the DROP here

Copy link
Contributor

@nastra nastra left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for fixing this @hantangwangd

@nastra nastra merged commit 788bea2 into apache:main May 16, 2024
31 checks passed
@nastra
Copy link
Contributor

nastra commented May 16, 2024

@hantangwangd could you also please backport this to Spark 3.3 / 3.4? Opening one PR where this is fixed for 3.3 + 3.4 should be fine. Thanks a lot

@hantangwangd
Copy link
Contributor Author

@nastra No problem, my pleasure!

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.

None yet

2 participants