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 crash on unexpected plugin slugs #767

Merged
merged 4 commits into from
Mar 26, 2024
Merged

Conversation

crazytonyli
Copy link
Contributor

Description

Fixes wordpress-mobile/WordPress-iOS#22891.

The crash happens when a WordPress plugin slug contains characters that are not in percentage encoding characters set, like % or non ascii.

I couldn't find such plugin in the plugin directory though. Also the guidelines (here and here) seem to indicate slug is url safe. But maybe there still could be unconventional plugin slugs in the real world...

Testing Details

See the added unit test.


  • Please check here if your pull request includes additional test coverage.
  • I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary.

Comment on lines 353 to 357
let _ = try await PluginDirectoryServiceRemote().getPluginInformation(slug: "%-is-not-allowed")
let _ = try await PluginDirectoryServiceRemote().getPluginInformation(slug: "中文")

// No assertion needed.
}
Copy link
Contributor

Choose a reason for hiding this comment

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

A suggestion for your consideration.

Suggested change
let _ = try await PluginDirectoryServiceRemote().getPluginInformation(slug: "%-is-not-allowed")
let _ = try await PluginDirectoryServiceRemote().getPluginInformation(slug: "中文")
// No assertion needed.
}
await XCTAssertNoThrow(try await PluginDirectoryServiceRemote().getPluginInformation(slug: "%-is-not-allowed"))
await XCTAssertNoThrow(try await PluginDirectoryServiceRemote().getPluginInformation(slug: "中文"))
}
}
func XCTAssertNoThrow<T>(
_ expression: @autoclosure () async throws -> T,
_ message: @autoclosure () -> String = "",
file: StaticString = #filePath,
line: UInt = #line
) async {
let error: Error?
do {
_ = try await expression()
error = nil
} catch let caughtError {
error = caughtError
}
XCTAssertNil(
error,
message().isEmpty ? "Expected to not throw, threw \(String(describing: error))" : message(),
file: file,
line: line
)
}

The motivation for this is that a test with no assertion looks odd to me. But, having said that, XCTest will fail a test test name() throws that threw an error, so it might be much of a muchness...

image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

XCTest will fail a test test name() throws that threw an error, so it might be much of a muchness...

That's my thinking too. XCTest kind of makes the "no throw" assertion for us.

@mokagio
Copy link
Contributor

mokagio commented Mar 26, 2024

@crazytonyli thank you for reviewing #764. It auto-merged and created conflicts with this branch, since I already had a copy checked out for the suggestion I left, I took the liberty of merging trunk into this to address the conflicts. My Git was able to auto-resolve them, which I'm not surprised given they were merely renames.

@mokagio
Copy link
Contributor

mokagio commented Mar 26, 2024

Also, @crazytonyli, should I ship a new version of the library, so we can point WordPress to it instead than a commit?

Again, given I made changes to the lib, including breaking changes, I'd be happy to wrangle.

@crazytonyli
Copy link
Contributor Author

Again, given I made changes to the lib, including breaking changes, I'd be happy to wrangle.

@mokagio That'd be nice. Thanks for that!

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