adding document scopes for now for easy start, will change it to presence scope

Missing use HTTP; trait — endpoint will not be registered

Update extends PresenceAction (which extends PlatformAction) but never declares use HTTP;. Every other HTTP action in the codebase that calls setHttpMethod / setHttpPath uses this trait (e.g. Teams/Http/Teams/Create.php, Presences/HTTP/Upsert.php). Without it the Utopia framework will not register PATCH /v1/presences/:presenceId as an HTTP route, so all update calls will silently 404 or be ignored.

not needed its alreay present

$user variable overwritten — fatal type error on API-key path

In the else branch, $user (typed as Appwrite\Utopia\Database\Documents\User) is overwritten with the return value of getDocument(...), which is a plain Utopia\Database\Document. This overwritten value is then passed to setPermission(Document $document, ?array $permissions, User $user, ...) on line 116, which type-hints the third argument as User. PHP 8 will throw a fatal TypeError on every API-key / privileged upsert that provides permissions.

// Store the fetched document separately; keep $user intact for setPermission
$fetchedUser = $dbForProject->getDocument('users', $userId);
if ($fetchedUser->isEmpty()) {
    throw new Exception(Exception::USER_NOT_FOUND, params: [$userId]);
}
$userInternalId = $fetchedUser->getSequence();
$resolvedUserId = $fetchedUser->getId();

userInternalId set with getId() instead of getSequence()

Every other module that writes a userInternalId field (Account MFA, Teams memberships, VCS installations) uses $user->getSequence(), not $user->getId(). getId() returns the external $id, making userInternalId identical to userId — the field stores the wrong identifier and indexes on _key_userInternal become useless.

its already updated

Multiple TODO comments indicate unresolved design decisions

The collection definition contains at least five // TODO: comments (type choice for userId/userInternalId, missing expiry default, hostname vs region semantics, source default field, perms_md5 index strategy). Unresolved TODOs in a merged schema definition create a migration burden — changes after the fact require a migration script for all existing rows.

Requiring userId on every PATCH is unnecessarily restrictive

The presence record already stores userId; a PATCH endpoint should update only the supplied fields. Forcing server-side callers to re-supply userId on every update (or receive a 400) makes partial updates awkward and diverges from the sparse-update pattern described in AGENTS.md. Consider removing the mandatory userId check from the update endpoint and only applying it to the upsert/create path.

yes that is what happening, we are not forcing server side to provide userId everytime but if its provided, it must be the server side and not client

mongodb and postgres adapter doesn't work on upsert based on unique indexes so manual upsert logic for this to have consistent and deterministic result
Failing cases might be -> user sending an unique $id for an already present user which will lead to create but due to unique index it will throw duplicate exception
And due to duplicate exception we again have to do this manually

Better to do it from start for mongodb and postgres

@abnegate can you share what can be in the hostname, is it the region? or the pod?(https://github.com/appwrite/rfc/pull/61/changes#diff-fb6f9b5a0d2472eb42988a79c2869de8bcb62540594d0d6f0aa85f5a775bddd5R100)

@abnegate I think we should proivide here the bulk deletion rather? In case of upsert, update, etc it kind of not useful
But in the delete, the admin might want to delete in bulk
WDYT?