Skip to content

feat: bump appwrite/appwrite to 23.*#181

Merged
abnegate merged 10 commits into
mainfrom
feat/sdk-23
May 11, 2026
Merged

feat: bump appwrite/appwrite to 23.*#181
abnegate merged 10 commits into
mainfrom
feat/sdk-23

Conversation

@premtsd-code
Copy link
Copy Markdown
Contributor

Summary

Bumps `appwrite/appwrite` to `23.*` so consumers can use the typed `Backups` SDK service shipped in 20.2+.

PHPStan-level fixes:

  • Drop `Runtime::DENO121/124/135` and `BuildRuntime::DENO121/124/135` (removed in SDK 23) from runtime mappings; `DENO140` onward retained
  • `Functions::create` / `Sites::create`: `specification` → `buildSpecification` + `runtimeSpecification` (SDK 21 split)
  • `importPasswordUser` return type: `?array` → `?\Appwrite\Models\User` (SDK 22 typed models)
  • `API::getRow`: call `->toArray()` since SDK 22+ returns typed `Row`

Known follow-up

Many other call sites in `Sources/Appwrite.php` and `Destinations/Appwrite.php` still use array-offset access on responses (e.g. `$response['rows']`, `$user['$id']`). Those paths will fail at runtime under SDK 23 and need a separate refactor pass to use property access.

Test plan

  • `composer lint` passes
  • `composer check` (PHPStan level 3) passes
  • `composer test` — non-infra tests pass (Supabase/NHost E2E require local Postgres)
  • CI

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 8, 2026

Greptile Summary

This PR bumps appwrite/appwrite from 19.* to 23.*, migrates array-offset access to typed property access across Sources and Destinations, and adds the variableId named argument to createVariable calls to support ID-preserving migration. The Reader/API adapter is fully updated to wrap SDK 23 typed objects via ->toArray().

  • Destinations/Appwrite.php: drops removed Deno 1.21/1.24/1.35 runtimes, splits specification into buildSpecification/runtimeSpecification, and updates importPasswordUser return type to \\Appwrite\\Models\\User.
  • Sources/Appwrite.php: broad migration from $response['key'] to $response->property; cursor-pagination now uses empty() guard for teams but retains unsafe $collection[count-1]->id before the empty-check for buckets and functions.
  • Sources/Appwrite/Reader/API.php: listDatabases, listTables, listColumns, listIndexes, listRows, and getRow all correctly call ->toArray(), resolving the previous SDK 23 runtime breakage for the database reader path.

Confidence Score: 3/5

The SDK 23 migration is largely correct, but two cursor-pagination paths in Sources/Appwrite.php can throw a TypeError on an empty page response, silently aborting a migration mid-run.

The $lastBucket and $lastFunction cursor lines compute $collection[count($collection) - 1]->id before the empty-page guard runs. When the SDK returns zero items, count - 1 is -1, PHP returns null for the undefined offset, and null->id throws a TypeError that the trailing ?? null cannot catch. Both paths are exercised on every storage and function migration.

src/Migration/Sources/Appwrite.php — the bucket and function cursor-pagination loops need the empty-guard applied before the ->id dereference, as was done for the teams loop.

Important Files Changed

Filename Overview
composer.json Bumps appwrite/appwrite from 19.* to 23.*, updates PHP constraint to >=8.2, and removes the platform override that was pinning PHPStan to PHP 8.1.
src/Migration/Destinations/Appwrite.php Migrates createVariable calls to SDK 23 named-argument form (adding variableId), splits specification into buildSpecification/runtimeSpecification, drops removed Deno runtimes, and updates importPasswordUser return type to typed User model.
src/Migration/Sources/Appwrite.php Broad migration from array-offset access to typed property access throughout; two cursor-pagination patterns ($lastBucket, $lastFunction) still compute $collection[count-1]->id before the empty-check guard, making them crash on an empty page response.
src/Migration/Sources/Appwrite/Reader/API.php All list methods now wrap SDK 23 typed objects in ->toArray() preserving the plain-array contract; getRow calls ->toArray() directly; $rowsResponse->total is accessed correctly without conversion.

Reviews (11): Last reviewed commit: "chore(deps): drop config.platform pin" | Re-trigger Greptile

Comment thread src/Migration/Destinations/Appwrite.php
Adds typed Backups SDK service support (cloud uses this). Fixes
PHPStan errors against SDK 23:

- Replace removed Runtime::DENO121/124/135 (kept ::DENO140 onward)
- Functions::create / Sites::create: specification → buildSpecification
  + runtimeSpecification (SDK 21 split)
- importPasswordUser return type: array → \Appwrite\Models\User|null
- API::getRow: call ->toArray() since SDK 22+ returns typed Row

NOTE: many other call sites in Sources/Destinations still use array
offset access on typed responses. Those paths will break at runtime
under SDK 23. This commit is the minimum to ship typed-Backups support
in cloud; a follow-up refactor will convert all array-offset access to
property access.
Comment thread composer.json Outdated
SDK 22+ returns typed Models without ArrayAccess, so existing
\$response['key'] patterns fail at runtime ('Cannot use object of
type Appwrite\Models\\\*List as array'). Convert all SDK call sites
in Sources and Destinations to property access:

- \$list['total'] / ['users'|'teams'|...] -> \$list->total / ->users
- \$user['\$id'] -> \$user->id (SDK 22+ drops \$ prefix)
- \$bucket['\$permissions'] -> \$bucket->permissions

API Reader keeps its array contract (matches Database reader, used by
existing callers): converts SDK typed responses via array_map ->toArray
at the I/O boundary.

\Appwrite\Models\Deployment param types added to
exportDeploymentData and exportSiteDeploymentData.

PHPStan level 7 finds zero remaining 'Cannot access offset on
Appwrite\Models\\\*' errors. Level 3 (project default) clean.
…Status)

Five runtime bugs missed in the previous regex pass; PHPStan level 8
caught them when checking against the SDK Models. Migration's resource
constructors expect plain arrays / strings, not the nested typed
objects SDK 23 returns:

- \$user->prefs is Preferences object -> use ->data array
- \$user->targets is array<Target> -> array_map(fn(\$t) => \$t->toArray())
- \$team->prefs same Preferences fix
- \$function->specification doesn't exist on FunctionModel any more;
  read runtimeSpecification ?: buildSpecification (SDK 21 split)
- \$site->specification same Site fix
- \$message->status is MessageStatus enum -> cast to string via __toString

PHPStan level 3 (project default) clean. Level 8 has no remaining SDK
type issues across Sources/Destinations/Reader.
…riable

SDK 23.1 added a required \$variableId 2nd parameter:
- Sites::createVariable(\$siteId, \$variableId, \$key, \$value, ?\$secret)
- Functions::createVariable(\$functionId, \$variableId, \$key, \$value, ?\$secret)

Pass the migration resource's id as \$variableId so the destination
preserves the source variable id.

Bumps appwrite/appwrite to 23.1.0 in composer.lock.
Comment thread src/Migration/Sources/Appwrite.php
SDK 23.1 inserted \$startCommand between \$buildCommand and
\$outputDirectory in Sites::create, which silently shifted positional
calls — outputDirectory landed in startCommand and adapter landed in
outputDirectory, causing testAppwriteMigrationSite to migrate sites
with empty adapter. Fixed by switching to named arguments.

Apply the same to:
- Functions::create
- Functions::createVariable
- Sites::createVariable

Named args are robust against future positional insertions in the
generated SDK.
Migrations from older Appwrite servers may still have functions
registered with deno-1.21 / 1.24 / 1.35. SDK 23 dropped those Runtime
factory methods. Rather than throwing 'Invalid Runtime' and breaking
the migration, transparently bump these deprecated runtimes to
deno-1.40, the nearest still-supported version (already mapped).
end([]) returns false, and PHP's nullsafe operator (?->) only
short-circuits on null. end($empty)?->id therefore throws TypeError
when the teams response is empty, breaking reportAuth for accounts
without teams. Replace with an explicit empty check.
Comment thread src/Migration/Sources/Appwrite/Reader/API.php
appwrite/appwrite 23.x (via SDK 22.0.0) requires PHP >=8.2.0, but
this lib's require.php was >=8.1 — composer install would fail on
PHP 8.1 consumers.

The previous top-level 'platform' key was silently ignored by
Composer (must live under 'config.platform'), which hid the
inconsistency locally. Move it under 'config.platform' and bump to
8.2 to match the require constraint.
Comment thread composer.json Outdated
Per review: pinning config.platform.php to 8.2 forces composer to resolve
against 8.2, which can hold back deps that need 8.3+. The "php": ">=8.2"
require constraint is the signal that matters.
@abnegate abnegate merged commit 0fca44f into main May 11, 2026
4 checks passed
@abnegate abnegate deleted the feat/sdk-23 branch May 11, 2026 08:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants