refactor(ios): use wordpress-rs connectivity error helpers - #580
Open
dcalhoun wants to merge 3 commits into
Open
refactor(ios): use wordpress-rs connectivity error helpers#580dcalhoun wants to merge 3 commits into
dcalhoun wants to merge 3 commits into
Conversation
XCFramework BuildThis PR's XCFramework is available for testing. Add the following to your .package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/580")Built from 8767e26 |
dcalhoun
force-pushed
the
refactor/ios-use-wprs-error-helpers
branch
from
August 6, 2026 17:24
b7fec3b to
2bfeb35
Compare
github-actions
Bot
added
the
[Type] Task
dcalhoun
marked this pull request as ready for review
August 6, 2026 20:32
Replaces the hand-rolled `WpApiError.RequestExecutionFailed` pattern matches with `isSiteUnreachable` and `isDeviceOffline`, added in wordpress-rs. Both call sites now use a typed `catch` and read the library property directly, so the demo app no longer defines its own vocabulary for this distinction. Drops the `error is URLError` fallback along with the helpers. Every throwing call in the enclosing `do` blocks goes through `WordPressAPI` — `apiRoot.get()` and `postTypes.listWithEditContext()` — so `WpRequestExecutor` has already rewrapped any `URLError` into a `WpApiError` by the time these run. The fallback could never fire. Refs #578 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Temporarily resolves wordpress-rs from the `pr-build/1488` snapshot branch so the demo app can build against `WpApiError.isSiteUnreachable` and `.isDeviceOffline`, which are not in the released 0.6.0. INTERIM — must be replaced with an exact version before merging. The snapshot branch is force-pushed on every CI run of Automattic/wordpress-rs#1488 and its S3 artifact lives under `pr-builds/1488/`, so neither is maintained once that PR merges. Swap to the release that carries the new API. Refs #578 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The `pr-build/1488` snapshot branch was deleted once that PR merged, taking its S3 artifact under `pr-builds/1488/` with it, so the previous pin no longer resolves. Repoints at `trunk-build`, the published mirror of trunk. Trunk itself cannot be consumed as a remote SPM dependency: its `Package.swift` sets `libwordpressFFIVersion = .local`, which expects `target/libwordpressFFI.xcframework` to be built locally by Cargo and is absent from a fresh checkout. `trunk-build` carries the same Swift sources but declares `.release`, fetching the prebuilt xcframework from the CDN. Pinned by revision rather than branch because `trunk-build` is force-pushed on every trunk CI run. `d70c99e1` is the build of trunk `c2f8a25f`, which carries `WpApiError.isSiteUnreachable` and `.isDeviceOffline`. INTERIM — must be replaced with an exact version before merging. No tagged release carries these helpers yet; the latest, `alpha-20260313.1`, predates Automattic/wordpress-rs#1488. Swap to the release that carries the new API. Refs #578 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dcalhoun
force-pushed
the
refactor/ios-use-wprs-error-helpers
branch
from
August 7, 2026 13:49
2bfeb35 to
8767e26
Compare
dcalhoun
commented
Aug 7, 2026
Comment on lines
+576
to
+577
| kind = revision; | ||
| revision = d70c99e1ff38772353bd8f6a81879320990a560e; |
Member
Author
There was a problem hiding this comment.
Is it safe to use a wordpress-rs commit hash for the Demo app or do we need to await a tag?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Replaces the iOS demo app's hand-rolled connectivity error classifiers with the equivalents added to wordpress-rs.
Closes #578.
Why?
SitePreparationViewmatchedWpApiError.RequestExecutionFailedwith five positional associated values to read a single nested reason — once for "site unreachable", once for "device offline". That is fragile: it breaks wheneverWpApiErrorgains a case, and it duplicates knowledge that belongs to wordpress-rs, which creates the distinction in the first place.Raised in review feedback on #572: "We should probably lower this into wprs on either the Swift or Rust layers."
How?
Both helpers are deleted and their call sites read the library property directly:
A typed
catchdoes the cast, so no wrapper is needed — and the demo app no longer defines its own vocabulary for a distinction the library already names.The
error is URLErrorfallback goes with them. Every throwing call in the enclosingdoblocks goes throughWordPressAPI—apiRoot.get()andpostTypes.listWithEditContext()— soWpRequestExecutorhas already rewrapped anyURLErrorinto aWpApiErrorby the time these run. The only remainingURLSessionreference in the file is theURLSessionConfigurationpassed intoWordPressAPI, so the fallback could never fire.Depends on Automattic/wordpress-rs#1488, which adds
isSiteUnreachable/isDeviceOffline.Follow-up: Android
#578 also covers bringing the Android demo app to parity — it currently discards the failure reason in
loadPostTypesand substitutes a hardcodedposttype, which is why the plain-permalink bug fixed in #572 went unnoticed there. That work is blocked on a wordpress-rs mapping inconsistency: the Kotlin executor maps a refused connection toHttpErrorwhile Swift maps it toNonExistentSiteError, soisSiteUnreachablecurrently answers differently per platform. Details in the "Known limitation" section of #1488.Testing Instructions
ios/Demo-iOS/Gutenberg.xcodeprojand let package resolution finish./etc/hosts, then open its Editor Configuration. Expect the error view with "A server with the specified hostname could not be found", not the offline fallback. This confirmsisSiteUnreachableandisDeviceOfflinereturn opposite answers for the same error.Verified on device: all three behave as described, and a full
xcodebuildof the demo app succeeds.Accessibility Testing Instructions
N/A — no user interface changes. The error and fallback paths are unchanged; only how they are detected differs.