iframe-proxy

ArnabChatterjee20k · 2026-10-16T14:30:53Z

Issue

Fixes #14342 — closing one of a user's realtime connections deleted their presence while another connection was still open.

Solution

Track presence with a connections counter on the one-per-user presenceLogs row (unique userId), counting the live sockets holding the user:

A socket's first presence message creates the row (connections = 1) or increments it; a later message from the same socket just refreshes its status.
On close the socket decrements the row; at 0 the row is deleted and the offline event fires — so closing one connection never removes a presence another still holds (🐛 Bug Report: Closing one realtime connection deletes the user's presence while another connection is still open #14342).
Every decrement is guarded by the row's presenceId, so a close can't touch a row already deleted and recreated.
The hold lives in connections[$id]['presence'] and is released on a clean close.

State::upsertForUserWithConnections and releaseConnectionForUser own the counter transitions — transactional, serialized against the decrement-to-zero delete — and triggerPresenceDeleted emits the shared offline side effects.

Alternatives Discovered

Per-worker counter (earlier revision of this PR): connections counted workers, with a per-worker in-memory holder index bumping the row only on a worker's 0↔1 transition. Dropped — connections are load-balanced, so sockets-per-worker ≈ 1 and the batching saved little while adding a second in-memory structure that could outlive a connection.
Synchronise upsert and close (fix(realtime): synchronise presence upsert and close #14597 open, fix(realtime): synchronise presence upsert and close #14461 closed): coordinate the race through external locking/Redis. Kept the DB row as the single source of truth here instead of adding a second consistency domain.

Replace the Redis/cache holder tracking with a `connections` counter on the one-per-user presenceLogs row = how many realtime workers currently hold the user. The row is deleted when it reaches zero. - Each worker keeps its holders in memory (Realtime::$presenceHolders) and touches the DB counter only on its 0<->1 transitions (first connection in, last connection out) -- heartbeats are in-memory, no per-message Redis. - State::recordPresence increments on a worker's first hold and refreshes the value otherwise; State::releaseHolder decrements and deletes + returns the row at zero. Both run in a forUpdate transaction, so the DB row lock serializes a decrement-to-zero delete against another worker's increment -- no Redis, no distributed lock, no reaper. - onClose releases the hold inline (prompt offline event) only when the worker's last connection for the user closes. - Re-auth carries the hold on same-user, releases the previous user on a user change. Schema gains `connections` + a V25 migration for existing rows. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

tenki-reviewer · 2026-10-16T14:30:59Z

Review complete. 🟠 3 high · 🟡 1 medium

📍 Findings outside the diff (4) — 🟠 3 high · 🟡 1 medium — defects on lines GitHub can't attach comments to

🟠 High — New presenceLogs case shadows the createCollection case

The new case 'presenceLogs': at src/Appwrite/Migration/Version/V25.php:228 shadows the later case 'presenceLogs': at line 424, whose branch calls $this->createCollection($id). PHP matches a value against the first case, so for any install where the presenceLogs collection does not exist yet (the exact installs the line 425 comment describes: upgrades that never ran V24), only the attribute-add path runs, it fails with a Console::warning, and the collection is never created.

🟠 High — Stale holder entry when connection record is missing at reauth

In the reauth handler, the same-user branch only restores the hold if (isset($realtime->connections[$connectionId])) (src/Appwrite/Realtime/Message/Handlers/Authentication.php:136-138), but unsubscribe() at line 100 has already unset that entry and it is only recreated when the connection has subscriptions to rebind. When the guard fails, the presenceHolders[$projectId][$userId][$connectionId] entry is left in place forever, so at close the hold lookup is null and the worker's count is never released — the user's row stays connections > 0 and the worker reports them online until the 30-day expiry. The same gap exists in the close path, which is gated on the connection entry still existing in app/realtime.php:1427.

🟠 High — Presence hold registered before DB write, never rolled back

The handler records the connection in $realtime->presenceHolders before calling recordPresence (src/Appwrite/Realtime/Message/Handlers/Presence.php:102-108), and nothing removes that entry when recordPresence throws (structure, conflict, or duplicate errors all propagate out of the handler). The stale entry makes every later message on that worker see firstWorkerHold = false, and at close time $workerStillHolds stays true, so the row's connections count is never decremented or deleted.

🟡 Medium — Usage trigger fires on every refresh, not just creation

The comment at src/Appwrite/Realtime/Message/Handlers/Presence.php:110 assumes connections == 1 means the row was just created, but the refresh path keeps the counter at \max($connections, 1) (src/Appwrite/Presences/State.php:165), so a row held by exactly one worker stays at 1 across refreshes. Every subsequent presence message re-satisfies the check and calls triggerUsage(..., 1), inflating the usage metric per message instead of once per online transition.

This PR switches presence online/offline tracking from per-connection rows to refcounted holds: a connection that subscribes with presence registers a hold in $realtime->presenceHolders, the row's connections counter is incremented under transaction, and the row is decremented or deleted as holds release on close or re-auth. Migration V25 backfills the new attribute and the e2e suite asserts the realtime delete event after re-auth.

Files	Change
`src/Appwrite/Presences/State.php`, `src/Appwrite/Realtime/Message/Handlers/Presence.php`	Transactional hold counting: `recordPresence` upserts the row and bumps `connections`; the handler registers per-worker holds and triggers usage on the first hold.
`src/Appwrite/Realtime/Message/Handlers/Authentication.php`, `app/realtime.php`	Re-auth and close paths release or restore the previous user's holds and rebuild the connection's presence key.
`src/Appwrite/Migration/Version/V25.php`, `app/config/collections/common.php`	Adds the `connections` attribute to `presenceLogs` in config and creates/backfills it in the V25 migration.
`tests/e2e/Services/Presences/PresenceRealtimeClientTest.php`	New e2e test asserting the presence delete event and 404 on GET after re-auth.

_{Reviewed commit: 7a70954}

Heartbeat/value-refresh messages (not a 0->1 transition) now do a plain sparse value update that leaves connections untouched -- no transaction, no forUpdate. Only the worker's first hold for a user takes the transaction. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Guard the usage +1 on firstWorkerHold so a heartbeat on a single-connection user (connections already 1) does not re-count it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

github-actions · 2026-10-16T14:33:25Z

Security rules

No new WARNING or ERROR findings from security rules.

19 existing findings tracked in .semgrep/baseline.json

php.appwrite.guest-write-without-abuse-limit (12)
php.appwrite.secret-compare-timing (5)
php.appwrite.weak-secret-env-default (2)

Posted by Checks / Rules. Re-runs update this comment in place. Rule details and baseline: .semgrep/README.md.

hansi-codes · 2026-10-16T14:35:31Z

🟢 Tier S · Ready to merge

The pull request adds a per-user presence connection counter and tracks each realtime socket’s hold so presence remains until the final hold is released. It updates the presence schema and migration, handles socket close and re-authentication cleanup, and adds coverage for counter transitions and related behavior.

Latest changes: The newest commits remove the hostname-based startup orphan sweep, its deletion helper, and the helper’s tests.

Verdict	New comments	Fixed	Still open
✅ Approved	0	1	0

📂 Walkthrough · 11

File	Change
`app/config/collections/common.php`	Adds the per-user connection counter to the presence collection schema.
`app/realtime.php`	Releases a socket’s presence hold on close and removes the hostname-based startup sweep.
`src/Appwrite/Messaging/Adapter/Realtime.php`	Documents the per-connection presence-hold metadata.
`src/Appwrite/Migration/Version/V25.php`	Migrates existing presence collections and creates the counter-enabled schema for legacy projects.
`src/Appwrite/Presences/State.php`	Implements transactional counter transitions, guarded releases, and shared offline side effects.
`src/Appwrite/Realtime/Message/Handlers/Authentication.php`	Preserves a socket’s hold on same-user re-authentication and releases it when the user changes.
`src/Appwrite/Realtime/Message/Handlers/Presence.php`	Acquires or refreshes the socket hold and records the presence row sequence on the connection.
`tests/e2e/Services/Presences/PresenceRealtimeClientTest.php`	Covers releasing the previous user’s hold after re-authentication.
`tests/unit/Messaging/MessagingTest.php`	Covers retaining presence-hold metadata in realtime connection state.
`tests/unit/Migration/Version/V25Test.php`	Covers adding the counter to existing collections and creating the legacy schema, including reruns.
`tests/unit/Presences/StateTest.php`	Covers presence counter transitions, row identity, and releases.

✅ Fixed since the last review · 1

~~Do not delete shared presence rows based on the last writer's host~~ · app/realtime.php:421

_{Reviewed the commits since 201a9f5 · Details · Comment @hansi-codes review to re-run, or mention @hansi-codes with a question.}

hansi-codes

🟡 Tier B · See the inline comments. Summary

- Record a connection's in-memory hold only after recordPresence commits, so a failed write can't leave a phantom hold that later decrements a count it never incremented. recordPresence retries a lost unique-userId create race as an increment instead of erroring. - On a presence delete event (HTTP or worker), clear this worker's stale holds for that user so a later close can't decrement a count the row no longer has. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

github-actions · 2026-10-16T14:40:16Z

✨ Benchmark results

Comparing main (before) → fix-realtime-presence-connections-counter (after).

Metric	Before	After	Change
🚀 Requests/sec	`210.8`	`217.35`	⚪ `+3.1%`
⏱️ Latency P50	`80.45 ms`	`79.33 ms`	⚪ `-1.4%`
⏱️ Latency P95	`189.28 ms`	`189.15 ms`	⚪ `-0.1%`

Per-scenario breakdown & investigation details

Metrics below reflect the current branch (after). Δ P95 compares against the base.

Scenario	P50 (ms)	P95 (ms)	Requests	RPS	Δ P95 (ms)
API total	`79.33`	`189.15`	`13,623`	`217.35`	`-0.13`
Account	`154.69`	`287.02`	`717`	`12.1`	`+12.14`
TablesDB	`76.62`	`146.05`	`7,409`	`120.48`	`-10.43`
Storage	`73.55`	`171.37`	`3,585`	`60.32`	`-10.12`
Functions	`114.09`	`217.87`	`1,912`	`32.92`	`+18.25`

Top API waits (after)

API request	Max wait (ms)
account.name.update	`494.55`
functions.delete	`457.11`
functions.variables.update	`398.95`
tablesdb.rows.create	`386.05`
storage.files.create	`380.95`

hansi-codes

🟡 Tier B · 1 blocking finding to address. Summary

- Reserve the worker-holder marker synchronously before the awaiting write, so two concurrent first messages on one worker can't both count as the first hold and double-increment. Roll the reservation back if the write fails. - Tag each hold with its row id and clear only holds on the deleted row, so a delete event for a superseded row can't erase a hold on a recreated one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The findings that requested changes are resolved. See the summary comment for what is still open.

releaseHolder now takes the hold's presence id and no-ops when the current row's id differs (the row was deleted and recreated since this worker's increment), so a stale close can't under-count a row it never counted -- defense in depth with clearPresenceHolders. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes

🔵 Tier A · See the inline comments. Summary

Concurrent first messages on one connection share the connectionId marker. Roll back only while it is still the reservation sentinel (true); if a sibling message already committed and wrote the row id, leave it, so a failed request can't erase a live hold and cause a premature release. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes

🟢 Tier S · Looks good to merge. Summary

- V25: fold the connections attribute-add into the existing presenceLogs case (which also createCollection) instead of a second case that shadowed it and skipped collection creation on installs that never ran V24. - Re-auth: carry the hold only when the same user's connection entry was restored; otherwise release it and drop the holder-index entry, so a hold can't outlive a stash onClose would need to release it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ArnabChatterjee20k · 2026-10-16T15:09:17Z

Thanks @tenki-reviewer — addressing the 4 summary findings:

presenceLogs migration case shadows createCollection — fixed in 211e2d7. The duplicate case 'presenceLogs': is removed; the connections attribute-add is folded into the existing case, which now createCollection()s it (for installs that never ran V24) and adds the attribute (for installs that already have the collection from V24).
Stale holder entry when the connection record is missing at re-auth — fixed in 211e2d7. The hold is carried over only when the same user's connection entry was restored; otherwise (user change, or the entry wasn't recreated) the holder-index entry is dropped and the worker count released, so a hold can't outlive a stash that onClose needs to release it.
Presence hold registered before the DB write, never rolled back — already fixed in 09269a1 / fe1269f: the reservation is rolled back on failure, and the rollback only removes its own sentinel so it can't erase a sibling's committed hold.
Usage trigger fires on every refresh — already fixed in 416530b: the +1 is guarded on firstWorkerHold, so it fires only on the global create, not on refreshes.

tenki-reviewer · 2026-10-16T15:09:25Z

Review complete. 🟠 2 high · 🟡 2 medium

💬 Inline comments (3)

🟠 Close racing a heartbeat permanently leaks the presence hold — Presence.php:125
🟡 Double-count users.presence when REST created the row — Presence.php:135
🟡 Migration swallows connections failure, records version anyway — V25.php:425

📍 Findings outside the diff (1) — 🟠 1 high — defects on lines GitHub can't attach comments to

🟠 High — Re-subscribe drops the presence hold key · Realtime.php:202–208 · unchanged line

// src/Appwrite/Messaging/Adapter/Realtime.php
202	        $entry = [
203	            'projectId' => $projectId,
204	            'roles' => \array_values(\array_unique(\array_merge($existingRoles, $roles))),
205	            'userId' => $userId ?? ($existing['userId'] ?? ''),
206	            'channels' => \array_values(\array_unique(\array_merge($existingChannels, $channels))),
207	            'presences' => $this->connections[$identifier]['presences'] ?? []
208	        ];

Realtime::subscribe() rebuilds the connection entry from a fixed whitelist that preserves the legacy plural presences map but omits the new singular presence hold key (src/Appwrite/Messaging/Adapter/Realtime.php:207). Any client subscribe message after a presence heartbeat silently erases the hold while the stale presenceHolders[projectId][userId][connectionId] entry survives. On close, onClose finds no hold and skips cleanup, and because the holder index still lists the dead connection, workerStillHolds stays true — the presence row is never decremented or deleted until its 30-day expiry and the user appears online forever. The previous code used the plural presences key, which subscribe() does preserve, so this is a regression from the key rename.

🧹 Nitpicks (1) — 🟢 1 low

🟢 Orphaned docblock now sits above clearPresenceHolders (Realtime.php:267) — The new clearPresenceHolders docblock was inserted after the old removePresenceFromConnections docblock (src/Appwrite/Messaging/Adapter/Realtime.php:267-275), so that stale block ('Dedup delete presence triggers… @return int Number of connections whose presences map was updated') now documents the wrong method.

The change introduces durable presence connection counting: a new connections integer attribute on the presenceLogs collection, incremented when a connection claims a presence row and decremented when its hold is released, with the realtime adapter tracking per-connection hold keys and the V25 migration backfilling the attribute. | Files | Change | |---|---| | app/config/collections/common.php, src/Appwrite/Migration/Version/V25.php | Adds the connections attribute (default 0) to presenceLogs and a migration to create it on existing installs. | | src/Appwrite/Presences/State.php | recordPresence/releaseHolder maintain the counter in a transaction and emit create/delete events when rows appear or vanish. | | src/Appwrite/Messaging/Adapter/Realtime.php | Tracks presence hold keys per connection and clears them on close/disconnect. | | src/Appwrite/Realtime/Message/Handlers/Authentication.php, Presence.php | Release prior holds on re-auth and route presence lifecycle messages through the new hold/counter flow. | | app/realtime.php | Wires presence hold handling into the connection close path and worker initialization. | | tests/e2e/Services/Presences/PresenceRealtimeClientTest.php | E2E coverage for presence realtime behavior. | Two high-severity bookkeeping races remain: re-subscribe can drop a connection's hold key, and a close/heartbeat race can permanently leak the presence hold. The migration also swallows attribute-creation failures while still recording the version.

_{Reviewed commit: 211e2d7}

hansi-codes

🔵 Tier A · Looks good to merge. Summary

Add regressions for a legacy project missing the presenceLogs collection (migration must create it with connections) and for an existing presenceLogs without the column (migration must add connections). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

tenki-reviewer

Adds persistent presence connection counting to realtime (a connections counter on presenceLogs with hold tracking in the realtime adapter) plus a V25 migration, fixing hold bookkeeping across re-auth, close, and delete paths.

Key findings

🟠 Re-subscribe drops the presence hold key — Realtime.php:202
🟠 Close racing a heartbeat permanently leaks the presence hold — Presence.php:125
🟡 Double-count users.presence when REST created the row — Presence.php:135
🟡 Migration swallows connections failure, records version anyway — V25.php:425

hansi-codes

🟢 Tier S · Looks good to merge. Summary

- If the socket closes during a first presence write, onClose runs before the hold is tagged and can't release it; the handler now detects the gone connection after the write, releases the row it created/incremented, and drops the reservation instead of resurrecting a dead hold. - recordPresence reports whether it actually created the row; usage +1 now fires only on creation, not on incrementing a row an HTTP upsert already counted. - V25: let the presenceLogs createCollection/connections failures propagate (createCollection is idempotent), so the version isn't recorded with a missing attribute. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes

🔵 Tier A · See the inline comments. Summary

If the final holder's socket closes mid-write and the cleanup deletes the row, the handler now emits presences.*.delete (not the online upsert), purges the list cache, and decrements usage when the deleted row was previously counted -- instead of announcing the user online after the row is gone. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Adds StateTest coverage for upsertForUserWithConnections (create = 1, second socket increments, same-socket refresh does not count, a stale/gone held row recounts or recreates) and releaseConnectionForUser (decrement, delete at zero, presenceId-guard no-op). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Addresses three review findings in the per-socket presence counter: - Same-id recreation: an HTTP delete + recreate with the same explicit presence id kept the id, so a stale socket's close could decrement and delete the replacement row another socket still held. The hold is now keyed on the row's internal `$sequence`, which a delete-and-recreate always changes, so a stale hold no longer matches the live row (upsert refresh check + release guard). - Lost create race left `created` true: reset `created`/`counted` at the start of each transaction attempt, so a retry that only increments no longer reports an online transition and over-counts usage. - Offline event vs user lookup: triggerPresenceDeleted now tolerates a transient user lookup failure and emits the delete event with an empty user, as the old close cleanup did, so subscribers are not left with stale online state. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes

🟢 Tier S · Looks good to merge. Summary

CI failures on the per-socket presence change: - V25 presenceLogs case: now that `connections` is in the collection config, createCollection() creates the row with it, so the following attribute-add raised Duplicate and failed the migration (and every V25Test that runs execute()). Catch the benign Duplicate; other failures still propagate. - PHPStan: drop a redundant is_string() on Document::getId() (always string), and assert the release decrement/delete via DB state instead of the nullable return, which tripped an impossible-type check. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…piry A silently dead realtime client (network loss, or a peer that vanished without a FIN) never ran onClose, so its presence lingered until the 30-day expiry (#14343). Configure Swoole's heartbeat so a socket idle past the idle time is closed and runs the normal onClose/release path; clients ping every ~20s, well within the window, so live connections are untouched. Shorten the realtime presence expiry from 30 days to 1 day as the backstop for a hard crash that fires no onClose at all. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A hard crash fires no onClose, so a dead instance's presence rows linger until expiry. On a clean boot every presenceLogs row tagged with this hostname is such an orphan (new connections are only accepted after onStart), so delete them across the console and every project, purging the list cache where rows were removed. CE only -- a Cloud host is shared across tenants on sharded databases, where a per-host sweep does not apply (#14343). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Realtime presence is upserted once per connection and never refreshed (a per-ping refresh is a DB write per connection, which doesn't scale). So a short expiry deletes live long-lived connections, since the row can't tell a held-but-stale presence from an orphan. #14343's real cases are handled without the expiry -- the heartbeat closes silently-dead sockets and boot reconciliation clears same-host crash orphans -- so the expiry stays a long, harmless far backstop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ffline Addresses two review findings on the hostname sweep: - Race: the detached go() runs while the server accepts connections, so a fresh presence upserted on this hostname mid-sweep could be deleted as an orphan. Capture a `$since` at boot and only sweep rows created before it; anything a live connection writes during the sweep is created after `$since` and left alone. - Side effects: the raw bulk delete bypassed the offline path, so usage was not decremented and no delete event reached other workers. Each orphan is now deleted individually and run through triggerPresenceDeleted (usage -1 + the presences.[presenceId].delete event), resiliently per row. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…heartbeat fix(realtime): detect dead presence sockets via heartbeat + boot reconciliation

hansi-codes

🟡 Tier B · 1 blocking finding to address. Summary

The CE orphan sweep runs asynchronously while new connections are already accepted. A reconnect increments the same per-user row in place, which keeps its $createdAt, so the row still matched lessThan('$createdAt', $since) and was deleted despite the fresh live hold. Select candidates by $updatedAt (the field a reuse actually moves) and delete through State::deleteOrphan, which re-reads under the same forUpdate row lock the increment takes and bails when $updatedAt >= $since. Whichever grabs the lock first wins: a mid-sweep reconnect advances $updatedAt and is skipped; a sweep delete lets the reconnect create a fresh row. A live hold is never lost. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes

🟡 Tier B · See the inline comments. Summary

Add StateTest coverage for deleteOrphan: a row not touched since boot is deleted, a row updated after $since (reconnected) is preserved, and a missing row is a no-op. The test caught that the guard compared $updatedAt to $since as raw strings. $updatedAt reads back in ISO form (2026-...T...+00:00) while $since is DB format (space-separated), so 'T' > ' ' made the comparison always true and deleteOrphan never deleted anything. Compare them as \DateTime instants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

fixed already

ArnabChatterjee20k · 2026-10-21T10:25:18Z

@hansi-codes re review

hansi-codes · 2026-10-21T10:26:22Z

[P1] Don’t delete a shared presence row based only on its last writer’s host. The boot sweep selects rows by hostname and age, then deleteOrphan() checks only whether $updatedAt changed since boot; it never checks whether other sockets still hold the row. A socket on host B can keep a hold on a row last written by host A without refreshing it. When A restarts, the sweep can delete that row and emit an offline event while B is still connected. The timestamp guard only protects writes during the sweep, not existing holds. See the candidate query and orphan deletion guard.

ArnabChatterjee20k · 2026-10-21T10:36:27Z

@hansi-codes

[P1] Don’t delete a shared presence row based only on its last writer’s host. The boot sweep selects rows by hostname and age, then deleteOrphan() checks only whether $updatedAt changed since boot; it never checks whether other sockets still hold the row. A socket on host B can keep a hold on a row last written by host A without refreshing it. When A restarts, the sweep can delete that row and emit an offline event while B is still connected. The timestamp guard only protects writes during the sweep, not existing holds. See the candidate query and orphan deletion guard.

This is already fixed

hansi-codes · 2026-10-21T10:37:14Z

…nstants" This reverts commit 201a9f5.

…ences" This reverts commit 7a16442.

…nection-heartbeat" This reverts commit 5d0b547, reversing changes made to 5f8f6c3.

hansi-codes

🟢 Tier S · Looks good to merge. Summary

ArnabChatterjee20k and others added 2 commits October 16, 2026 20:02

fix(realtime): only count presence usage on the global create

416530b

Guard the usage +1 on firstWorkerHold so a heartbeat on a single-connection user (connections already 1) does not re-count it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hansi-codes Bot reviewed Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

Comment thread src/Appwrite/Presences/State.php Outdated

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

Comment thread src/Appwrite/Presences/State.php Outdated

hansi-codes Bot previously requested changes Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

Comment thread src/Appwrite/Messaging/Adapter/Realtime.php Outdated

hansi-codes Bot reviewed Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

hansi-codes Bot approved these changes Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Migration/Version/V25.php Outdated

tenki-reviewer Bot reviewed Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

Comment thread src/Appwrite/Migration/Version/V25.php

hansi-codes Bot approved these changes Oct 16, 2026

View reviewed changes

hansi-codes Bot reviewed Oct 16, 2026

View reviewed changes

Comment thread src/Appwrite/Realtime/Message/Handlers/Presence.php Outdated

ArnabChatterjee20k and others added 2 commits October 19, 2026 14:18

hansi-codes Bot approved these changes Oct 19, 2026

View reviewed changes

ArnabChatterjee20k and others added 4 commits October 19, 2026 15:36

removed comments

baff064

removed comments

2d32588

ArnabChatterjee20k mentioned this pull request Oct 19, 2026

fix(realtime): detect dead presence sockets via heartbeat + boot reconciliation #14661

Merged

ArnabChatterjee20k and others added 3 commits October 19, 2026 16:03

abnegate approved these changes Oct 20, 2026

View reviewed changes

Merge pull request #14661 from appwrite/fix-realtime-dead-connection-…

5d0b547

…heartbeat fix(realtime): detect dead presence sockets via heartbeat + boot reconciliation

hansi-codes Bot previously requested changes Oct 21, 2026

View reviewed changes

Comment thread app/realtime.php Outdated

hansi-codes Bot reviewed Oct 21, 2026

View reviewed changes

Comment thread src/Appwrite/Presences/State.php Outdated

ArnabChatterjee20k added 3 commits October 21, 2026 16:16

Revert "test(realtime): cover deleteOrphan timestamp guard; compare i…

29127af

…nstants" This reverts commit 201a9f5.

Revert "fix(realtime): keep boot sweep from deleting reconnected pres…

bea4c04

…ences" This reverts commit 7a16442.

Revert "Merge pull request #14661 from appwrite/fix-realtime-dead-con…

c8b09f8

…nection-heartbeat" This reverts commit 5d0b547, reversing changes made to 5f8f6c3.

ArnabChatterjee20k mentioned this pull request Oct 21, 2026

fix(realtime): dead-connection heartbeat + boot reconciliation #14717

Draft

hansi-codes Bot approved these changes Oct 21, 2026

View reviewed changes

ArnabChatterjee20k merged commit ba6e159 into main Oct 21, 2026
66 checks passed

ArnabChatterjee20k mentioned this pull request Oct 21, 2026

fix(realtime): prevent concurrent presence writes on one socket from leaking a hold #14724

Open

ChiragAgg5k mentioned this pull request Oct 21, 2026

chore: prepare 2.6.0 release #14730

Merged

6 tasks

Sunbelt Computer Software

PL/B Language Development and Support

Conversation

ArnabChatterjee20k commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue

Solution

Alternatives Discovered

Uh oh!

tenki-reviewer Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Security rules

Uh oh!

hansi-codes Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🟢 Tier S · Ready to merge

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✨ Benchmark results

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

ArnabChatterjee20k commented Oct 16, 2026

Uh oh!

tenki-reviewer Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💬 Inline comments (3)

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tenki-reviewer Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hansi-codes Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ArnabChatterjee20k commented Oct 21, 2026

Uh oh!

ArnabChatterjee20k commented Oct 16, 2026 •

edited

Loading

tenki-reviewer Bot commented Oct 16, 2026 •

edited

Loading

github-actions Bot commented Oct 16, 2026 •

edited

Loading

hansi-codes Bot commented Oct 16, 2026 •

edited

Loading

github-actions Bot commented Oct 16, 2026 •

edited

Loading

tenki-reviewer Bot commented Oct 16, 2026 •

edited

Loading

tenki-reviewer Bot left a comment •

edited

Loading