fix(plugins): self-heal incompatible drivers at connect instead of blocking (#1552)#1555
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 697644eeb6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| def compatible_kits(plugin): | ||
| return sorted({ | ||
| binary.get("pluginKitVersion") | ||
| for binary in plugin.get("binaries", []) | ||
| if binary.get("pluginKitVersion") is not None | ||
| }) |
There was a problem hiding this comment.
This readiness check collapses all binaries into a single set of PluginKit versions, so a plugin with only an arm64 binary in the supported range and an outdated/missing x86_64 binary still passes. The release job in .github/workflows/build.yml ships both build-arm64 and build-x86_64, and the plugin publish workflow writes architecture-specific registry entries, so after a breaking PluginKit floor bump this can allow the app release even though Intel users will still have no loadable driver binary.
Useful? React with 👍 / 👎.
…nce network retriggers
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 385412037a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if availableKits.contains(where: { $0 >= minimumKitVersion && $0 <= currentKitVersion }) { | ||
| return .updateAvailable(registryPlugin) |
There was a problem hiding this comment.
When the registry entry still has an old binary in the app's PluginKit range but its plugin-level minAppVersion has moved past the running app, this returns updateAvailable and the rejected-plugin UI shows an Update Now button. That update cannot succeed because validateRegistryCompatibility rejects registryPlugin.minAppVersion before downloading, so older app versions with retained compatible binaries get a misleading/retryable update path instead of the Update TablePro path.
Useful? React with 👍 / 👎.
1 participant
Fixes #1552.
Problem
After an app update that bumps the PluginKit ABI (v0.48.0 went 17 to 18 to turn on Swift Library Evolution), registry plugins installed against the old kit are rejected. Opening a connection shows "no compatible build is available yet", a second click shows "plugin not installed", and the only recovery is quitting and reopening. This recurs on every release that bumps the kit.
Root cause (three)
validateBundleVersions) requires an exact match and fires before the bundle loads, so a kit-17 plugin is rejected outright even though the framework is now resilient.noCompatibleBinaryis treated as a permanent failure, and nothing re-runs reconciliation while the app is open, so only a relaunch recovers.What changed
A. Floor gate.
minimumCompatiblePluginKitVersion = 18; the gate accepts the range[floor, current]and only blocks plugins newer than the app. Additive bumps (18 to 19) no longer reject installed plugins. Today floor equals current, so behavior is unchanged until the next bump.B. Graceful self-heal at connect.
noCompatibleBinaryis transient when the registry has not published the current-kit binary yet (still permanent when the registry only has a newer-kit binary, which needs an app update).ensurePluginReadyre-runs reconciliation at connect and on network reachability, so the driver updates in the background and the connection proceeds. No quit and reopen. The "error then a different error on the second click" is gone because the rejected entry stays consistent.C. Distribution.
resolvedBinaryselects the highest binary kit within[floor, current], so an additive bump is served by the existing binaries with no re-publish. The manifest is served through jsDelivr and purged on publish. Aregistry-readinessjob fails the app release until every database driver has a compatible binary.Kit-17 plugins were built before Library Evolution, so they cannot load under kit-18 and must update once. 17 to 18 is the last forced break; the floor gate stops it recurring from 18 to 19 on.
Also included
This branch is stacked on the Plugins-settings rejected-banner refactor (the two earlier commits): the unloaded-plugins banner scrolls instead of pushing the list off screen, shows each plugin's real icon, and only offers Update when a compatible build exists.
Testing
scripts/check-registry-readiness.pyvalidated against the live registry (floor 18 / current 18 ready; floor 18 / current 19 also passes off existing kit-18 binaries).Review notes
build-plugin.yml, theregistry-readinessgate inbuild.yml) run only in Actions and were not verified end to end locally.