mirror of
https://github.com/HeyPuter/puter.git
synced 2026-11-07 06:23:05 +00:00
Daniel Salazar
5d34e803ff
* fix(events): queue every row's single delivery before any handler runs A dispatch queued each matched single row's event and then waited on that row's hand-over, which can be a whole handler run, before queueing the next row's. An event matching several rows queued the later ones only after the earlier handlers finished, and lost them if the process stopped in between. A batched filesystem write did the same across its entries. The event is now queued in line and the hand-over runs detached; anything it doesn't finish is retried by the pending sweep. A hand-over that throws no longer raises the 'could not be queued and is lost' alarm, since the event is still queued. * perf(events): address an app's events worker from a cached handler set Every handler invocation read the app's handler set (names and hashes) from the primary database to work out which script to call. The delivery path now reads it through a Redis cache. Publishing, updating or removing a handler, and deleting the app's handlers, drop the entry on this node and every peer, so only a read that raced one of those writes can address the superseded script, for at most 30 seconds. An empty set isn't cached. Deploys and the events-worker listing still read the primary. * perf(events): skip leased queues without a database read, and sweep in parallel The pending sweep read each queue's subscription row from the primary database before finding out whether anything in the queue could be claimed. A queue whose head is in flight or waiting out a retry now goes to the back of the line on a Redis check alone; its row is read once the lease lapses. The backstop re-check of a queued row's access waits for that lapse too, and nothing is handed out in the meantime. The pass also worked through its subscriptions one at a time, so one slow handler run held up every queue behind it. It now works on up to ten at once. * fix(events): don't count a wait for a dispatcher connection as a handler timeout Invocations share one pool of connections to the events dispatcher per process, and the invoke timeout started when a call was made, not when it got a connection. With the pool busy, a call could spend its timeout waiting, be reported as a handler that ran past it, and count toward suspending a subscription whose handler never ran. A call now waits for a free connection before its timeout starts. A call that waits more than half the timeout for one fails as Puter's (unavailable): retried on the usual schedule and not counted, as the documented failure rules already say. Wait and run together stay inside the worker lease. * fix(events): end a background row whose consent a delivery finds withdrawn Withdrawing an app's events:background consent is settled by a listener on the node that handled the revoke. If that settle never ran or failed, the row stayed in service: every delivery found the consent gone, minted no token and was deferred, so the backlog was retried forever and the row was never suspended or reported. When the delivery path's consent check answers no, it now runs the same revocation settle (permission_revoked, backlog purged, holder told, worker session revoked), one at a time per holder and app. A consent check that throws still only defers the delivery. * perf(auth): record no session or user activity for events handler calls Every API call an events handler made authenticated through its worker session and touched the session and the user, so background handler runs wrote session and user activity rows on the primary database (each at most once a minute), and replaced the session's last IP and user agent with the worker runtime's. Calls made with an events handler token no longer touch either. A handler run isn't the user being active, and the handler session expires only when it is revoked, so nothing reads its activity to keep it alive. The handler session's last activity in the session list now reads as when it was created. * fix(events): settle withdrawn consent only on a fresh answer The delivery path's consent check reads through the permission scan cache and the cached user-to-app grants, which can trail a grant, for example on a node that cached the app's grants before the consent was given. A stale no then ended the subscription for good (permission_revoked, backlog purged, holder told, worker session revoked), where before it only deferred the delivery until the caches caught up. Before settling, the no is now asked again with a new `primary` scan option, which skips the scan cache and reads user-to-app grants from the primary database. Only a fresh no settles. A fresh yes, or a check that throws, leaves the delivery deferred. * test(events): assert no forwarded delivery, not no traffic at all The region's own connect announces presence to its peers on the forward queue's next flush. Now that a dispatch returns before the hand-over, the wait for the socket send can outlast that flush, and the test saw the presence announce as forwarding. * fix(events): budget the settles deliveries start for withdrawn consent A settle a delivery starts when it finds background consent withdrawn ends rows for good. If the permission check itself answered no wrongly, every row a delivery reached would be suspended, its backlog purged and its holder told, with nothing to bring it back. Each process now settles at most 20 such pairs a minute. Past that, the rest stay deferred, as a cached no always left them, and a warning alarm says so. A spent budget skips the fresh read too. A pair a fresh read just found consented isn't read again for a minute, so a stale cached no costs one primary read rather than one per delivery. Each settle is logged.