Add API key migration support#183
Conversation
…d-api-key-migration # Conflicts: # src/Migration/Destinations/Appwrite.php # src/Migration/Sources/Appwrite.php
Greptile SummaryThis PR adds
Confidence Score: 3/5Not safe to merge until the known unresolved null-safety bugs are fixed; every real-world key without an expiry date or that has never been accessed will throw a TypeError and fail export entirely. The export loop in Sources/Appwrite.php passes $key->expire and $key->accessedAt directly from the Appwrite SDK response into the ApiKey constructor, which declares both parameters as non-nullable string. The SDK returns null for both fields on keys with no expiry and keys that have never been used — both are extremely common in production projects. A TypeError thrown inside the pagination loop halts the entire export of API keys. This was identified in a previous review round but the constructor types and the construction site were not updated to apply the same ?? '' guard that fromArray already uses. src/Migration/Sources/Appwrite.php (exportApiKeys construction site) and src/Migration/Resources/Integrations/ApiKey.php (constructor parameter types for expire and accessedAt) Important Files Changed
Reviews (8): Last reviewed commit: "Pass through resource permissions to cre..." | Re-trigger Greptile |
Source uses Project SDK (listKeys with cursor pagination); destination writes keys directly via dbForPlatform, matching the platform pattern.
$this->headers/endpoint/key were only read by the inherited call() method which the destination no longer invokes. STATUS_ERROR is never set inside createPlatform/createApiKey (they throw), so the guard only needs SKIPPED.
Reverting the wider cleanup — those properties are part of the inherited Target surface, not the headers issue under review.
Matches the existing platform pattern. Source-side SDK Key model doesn't expose $permissions today so this is [] in practice (same as platforms), but the hook is in place for when source can populate it.
SDK strips $permissions from Key responses so we can't copy from source; match the upstream createKey controller default since dbForPlatform.keys is gated by endpoint scope, not document perms.
Drop the endpoint-scope tangent — the comment is about why we picked this value, not about whether doc perms get enforced.
projectInternalId is a written-but-not-queryable legacy column on the keys collection (upstream filter uses resourceInternalId + resourceType). Mirror that here so the duplicate-check find() doesn't error out.
Drop the removed projectInternalId/projectId legacy fields and use empty permissions, matching the current server-ce Project/Keys/Create action exactly.
Mirror createPlatform's pattern. Resolves to [] today since the SDK doesn't expose $permissions on Key responses, matching the upstream createKey endpoint default. Hook is in place if/when the SDK starts emitting permissions.
Summary
ApiKeyresource, source export via console headers, destination import).Platformresource).feat-platform-db-access(PR Add platform migration support #154), which switches platform listing/export from console-key HTTP calls to theProjectSDK service withbuildQueries.Notes
projectService->listPlatforms/exportPlatforms($batchSize).exportWithConsoleHeaderswrapper.Test plan
composer install && composer test(vendor not present in worktree — please run locally)composer lint && composer formatreporttotals forapiKeyandplatformresource types