mirror of
https://github.com/logos-co/logos-protocol.git
synced 2026-08-27 12:01:15 +00:00
Dario LipicarandClaude Opus 5
07b0fb1c64
* fix: make isConnected() mean connected, and stop the log claiming it QRemoteObjectNode::connectToNode() returns false only when the URL SCHEME is unregistered -- it never contacts the peer. Our registry URLs are COMPUTED rather than discovered (logos_instance.h: local:logos_<module>_<instanceId>), so they are identical whether or not the module exists. Latching m_connected from that return therefore made isConnected() answer "yes" for modules that were never loaded, which made every `if (!client->isConnected()) return;` guard in the codebase DEAD CODE. Callers then paid a 20 s waitForSource per call, twice over, because the token handshake tries capability_module first. Measured in Basecamp with package_manager absent: ~417 s of blocked GUI thread on macOS and 361 s on Linux before the window appeared, and over 900 s under load. Not a Windows bug -- the Windows port merely exposed it. isConnected() now also requires a listener at the endpoint. For `local:` that is a direct socket / named-pipe probe, which costs microseconds precisely in the case that used to cost 20 seconds; any other scheme keeps its previous behaviour. Two logging changes, because the diagnostics cost more than the defect: "Successfully connected to registry" asserted a connection that often did not exist and sent three separate investigations to the wrong place -- it now says a connect attempt started and makes no claim about the peer. And requestObject warns BEFORE a doomed wait instead of going silent for 20 s and then reporting failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: let event subscriptions survive a module that is not reachable yet requestObject() answers "is the module there RIGHT NOW", and every subscriber in this codebase asks at the one moment the answer is no: a module's init(), a UI backend's onContextReady(), a QML view's Component.onCompleted. All of those run while the dependency's host process has been spawned but has not called listen() yet. The subscriber then gave up permanently -- lp_subscribe returned nullptr with no log at all, and callers turned that into a `false` the documented example discards. Method calls kept working through the same window because acquireCachedObject() reaches the replica by a path that never asks, so the symptom was "events are broken", not "the subscription never happened".1238316(isConnected() means connected) is what made this deterministic rather than lucky, and it must not be reverted -- it removed ~417 s (macOS) / 361 s (Linux) of blocked GUI thread at Basecamp startup. So the subscription becomes deferrable instead. - LogosTransportAsyncAcquire: a sibling interface (dynamic_cast, like LogosObjectErrorChannel) so LogosTransportConnection's installed vtable is unchanged. requestObjectWhenAvailable() registers interest and returns; it never blocks and never spins a nested event loop. - qt_remote implements it by acquiring a dynamic replica before the peer exists -- legal, free, and armed by the node's existing 250 ms reconnect loop, so it adds no polling. Delivery is deferred one event-loop turn because stateChanged fires from inside onClientRead (the refresh_balances re-entrancy SIGSEGV). - LogosAPIConsumer::onEventWhenAvailable() holds the pending subscriptions, arms them when the object appears, shares ONE handle per object (separate from the call cache, so a call re-acquiring a stale handle cannot silently kill a live subscription), and re-arms them after reconnect(). Unbounded in time on purpose -- a module can be installed mid-session -- but bounded in noise: one warning at 3 s, one at 60 s, a log line when it arms, and a loud abandon when the transport proves it impossible. - lp_subscribe routes through it, which fixes the same defect for every C++/Nim/Rust module and UI backend without touching qt-sdk or any generated code. tests/protocol/test_deferred_subscription.cpp pins all three layers, each with a published-first control so a red case cannot be a mis-wired fixture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: close the remaining silent-failure holes in deferred event subscriptions The deferred-subscription registry from the previous commit fixed the reported defect, but review found six ways it could still lose a subscription without saying so — five in the registry itself, one in the plain transport's host — and every one of them lived in a cell with no test. All of its tests ran in Remote mode; three of the four transports had none at all. Registry (cpp/logos_api_consumer.cpp): * An already-present module was deferred to the first 250 ms tick on every transport without a deferred acquire, and every event emitted in that window was dropped. lp_subscribe used to attach synchronously and deliver them, so this relocated the silent event loss rather than removing it. startAcquire() now reports which of three answers the transport gave, and only an Unsupported answer takes the one synchronous requestObject() — which is also what keeps that call structurally away from qt_remote, whose requestObject() enters waitForSource()'s nested event loop even at timeout 0. Previously that invariant lived in a comment, and tick() could reach it whenever acquireDynamic() returned null. * reconnected() put every armed subscription back in the pending set but never restarted the timer, which takeMatching() had stopped when they armed. Since tick() is the sole driver of both the retry and the watchdog, a reconnect left the subscription dead AND silent — quieter than the "not connected" warning it replaced. * armAgainst() released a stale handle while entries were still attached to its event helper. Those entries stayed in m_armed, never fired again, and reported as healthy. They are now revived and re-armed against the new handle. * The retry timer ran forever at the 5 s cap with nothing to do. It now stops once every pending entry has an acquire in flight and has said everything it will say, and restarts when that changes. * A cancelled subscription had no way to leave the registry, so lp_unsubscribe left it holding the timer up and warning about a subscription nobody wanted. onEventWhenAvailable() now returns an id; cancelEventSubscription() and eventSubscriptionState() are its counterparts, and lp_unsubscribe uses them. Plain transport (cpp/implementations/plain/plain_transport_host.cpp): * onSubscribe() dropped a Subscribe for an object that was not published YET — which is exactly when consumers subscribe — and the consumer could not know, because requestObject() had already succeeded. Publishing also overwrote the sink table wholesale, so a republish took every subscriber down with it. The sinks now live in a table keyed independently of publication. Also adds lp_pending_subscriptions() to the C ABI. The Qt consumer has had this visibility all along and the C ABI had none, which is why a subscription that silently never armed was undetectable from Rust, Nim or a universal C++ module. tests/protocol/test_event_delivery_matrix.cpp pins the product rather than a sample of it: 3 transports x 2 provider kinds (Qt-native and universal/std, which reach the wire by different conversions) x 2 consumer paths (onEventWhenAvailable and lp_subscribe) x 6 timings, plus mock and the non-blocking guard. Every delivery case has a control that is green independently of these fixes. One thing that is NOT fixed and is now stated in the contract: arming is not retroactive and no transport buffers, so a module that emits a one-shot "ready" event synchronously inside its own init() can still be missed. That window is inherent to the transport — the blocking requestObject() this replaced had it too — but "subscriptions survive a late module" is not "no event can be missed". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: name the QtRO invariant the stale-handle revive rests on * test(events): state what the non-blocking guard can and cannot catch The acquireCount assertion catches a retry that polls qt_remote's blocking requestObject() in the ordinary case. It cannot reach the narrow one -- the poll is only reachable when the transport declines a deferred acquire while still reporting connected, which needs acquireDynamic() to return null and is not forcible from outside. That case is held shut by control flow instead, and saying so is better than leaving a reader to assume the test covers it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: make the async-acquire contract and lp_subscribe's return honest Both from review on #47, both real. The LogosTransportAsyncAcquire contract promised that a true return means onReady "WILL be invoked exactly once". It will not: RemoteTransportConnection parents every in-flight PendingAcquire to m_pendingAcquires, which is reset at the top of the destructor and rebuilt on reconnect, so an accepted request is cancelled silently with no callback whenever the connection it belongs to goes away. The contract now says AT MOST once, names both cancellation triggers, and states what a caller has to do about them — re-issue after a reconnect, or carry its own deadline. It also records that the layer above already does the first, which is why a subscription made through onEventWhenAvailable() survives something the raw transport call does not. That asymmetry is the reason to prefer the consumer API, and it was previously implicit. lp_subscribe returned a non-null lp_subscription even when onEventWhenAvailable refused and returned 0, leaving the caller with a handle that can never fire while the ABI documents NULL as the one signal that the arguments were refused. It now checks sub->id and returns nullptr. That second one is defensive rather than a live bug, and the code says so: the guard at the top of lp_subscribe already rejects an empty event name and a null callback, and lp_client_create rejects an empty target, so the three inputs that make onEventWhenAvailable() return 0 cannot all arrive there today. No test drives it. The two contracts simply have to agree, and one of them changing is how they would stop agreeing. 374/374 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: stop lp_unsubscribe deadlocking, without dereferencing a freed client lp_unsubscribe took ownerGuard->mutex and, while holding it, called cancelEventSubscription(), which marshals to the owner thread with a BLOCKING queued connection. The delivery callback lp_subscribe installs runs ON that thread and takes subGuard->mutex then clientGuard->mutex — and clientGuard IS ownerGuard, both assigned from client->guard. Lock-order inversion. It also hung outright once the owner's event loop had stopped, which is exactly when a language binding drops its subscription handle. The first attempt at this dropped the guard entirely and checked `alive` inside the posted lambda. That was a use-after-free: QMetaObject::invokeMethod dereferences the target (it reads object->thread()) before the lambda can run, and lp_client_destroy sets alive=false and deletes the client synchronously — so the check was unreachable on the exact ordering lp_subscription's own comment documents as supported. Proven rather than argued: with MallocScribble=1, a test that destroys the client before unsubscribing segfaulted 6/6 with the guard removed and passed 6/6 with it restored. So the guard is held across the POST and not across the cancel. Both halves are load-bearing, and the distinction is the whole fix: posting never waits on the owner thread, so holding the mutex across it cannot invert; only the blocking marshal ever had to move. Consequence, now stated in the ABI header: un-registration is EVENTUAL. The callback-will-not-fire guarantee stays synchronous and unconditional, but lp_pending_subscriptions() may still list a just-cancelled subscription until the owner thread runs, and if the client is destroyed first the cancellation never runs at all — correct, since the registry died with it. The matrix test now pumps for the drain instead of asserting it happened synchronously. 374/374 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: arm a subscription immediately when the module is already reachable Deferral introduced a narrower version of the loss it removed. The common consumer shape is a call followed by a subscription in the same function -- wallet-ui's backend calls get_chains() and subscribes on the next line, the tutorial's C++ UI backend does the same. Before deferral the generated Qt wrapper acquired synchronously, so the subscription was live before on() returned and an event emitted straight after was delivered. Holding it until the next event-loop turn silently drops that event. Measured on the generated-wrapper harness: 1/1 delivered pre-migration, 0/1 after, over 3 runs. LogosTransportAsyncAcquire gains tryAcquireNow(): hand back a handle ONLY if that costs nothing -- for qt_remote, a replica that is already Valid, which is exactly the state a prior call leaves behind since QtRO shares one replica implementation per object name on a node. It must never block, never spin a nested event loop and never wait on a peer; "not immediately available" is an answer and the caller falls back to the deferred path. Default returns nullptr, so a transport that cannot answer cheaply simply does not. Delivering inline here is safe for the reason the never-synchronous rule exists: that rule protects against re-entering the transport's READ stack from a stateChanged callback. tryAcquireNow runs on the subscriber's own stack. The new matrix case fires ONCE, synchronously, with no pumping in between -- re-firing would hide the exact gap under test -- and states the transport difference rather than papering over it. Subscription registration is local on qt_remote (attach to a held replica) and qt_local (connect an in-process signal), so delivery there must be instant. On plain it is a wire frame to the host, so instant delivery was never on offer and never was before this change either; that leg asserts it still arms and delivers. Also de-flaked EventDeliveryNonBlocking: its heartbeat COUNT over a fixed wall-clock window measures the machine, not the code. The gap assertion is the one that means something; the count is now only a floor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: stop tryAcquireNow leaving a dangling facade in QtRO's connect liste9f82acintroduced a use-after-free. tryAcquireNow() acquired a dynamic replica and, when it was not already Valid, deleted it. That is not safe: QtRO shares one replica IMPLEMENTATION per object name per node, and while that implementation is still waiting for the source's metaobject it records every facade built on it as a RAW pointer in QConnectedReplicaImplementation::m_parentsNeedingConnect. ~QRemoteObjectReplica is an empty body, so destroying a facade never deregisters it, and the implementation dereferences the whole list when the class definition arrives. So each probe of an unreachable module left one dangling pointer behind. WHY IT HID. The first probe owns the only implementation and takes it down with itself, so a single subscription is harmless. It needs a second subscription whose implementation is pinned by an in-flight PendingAcquire before a freed facade can outlive its implementation. A consumer subscribing once sees nothing; the QML plugin shape -- a view registering every event it cares about up front -- dies. REPRODUCED, 4 runs of 4, serially as well as in parallel, in logos-view-module-runtime's existing suite (unchanged from master, and green there against this same protocol checkout): LogosQmlBridge: subscription accepted for "echo_module" :: "ev13" Received signal 10 (SIGBUS), code 1, for address 0x5a SIGBUS code 1 is BUS_ADRALN -- a misaligned atomic access on a garbage base read out of a recycled heap block, in the event loop rather than at the call site, which is why it reads as a mystery crash rather than as a subscription bug. PROVEN, before writing this fix, by commenting out that single `delete replica`: the same suite went 4 failures -> 6/6 with no other change. With this fix: 6/6. THE FIX IS TO PARK, NOT TO FREE. One probe per object name, parented to m_pendingAcquires -- which both the destructor and reconnect() already destroy BEFORE the node, so the implementations die in the same breath and freeing them there is safe. Ownership transfers out only when the replica reaches Valid, by which point the implementation is configured and is no longer holding the facade. It costs one idle replica per name until it goes Valid or the connection dies. AND REMOVE THE MULTIPLIER: beginAcquire() probed on EVERY add(), ahead of startAcquire() and therefore ahead of the m_acquiring one-acquire-per-object guard. tick() already applies that filter; beginAcquire() was the one caller that did not, which is what turned one probe per module into one per subscription. While an acquire is in flight its PendingAcquire already holds a replica and will arm every waiting entry at once, so the probe buys nothing there. Not QML-specific: lp_subscribe reaches the same entry point. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>