Repository navigation
fix(intercept): embedded interceptStatus() caches the FFI start and goes stale when the shared slot changes via the admin plane - #317
Merged
Conversation
…e once one is served The C-ABI and the embedded admin plane share one intercept slot (rift#521), so the plane's GET /intercept already reports an FFI-started listener. The cached FFI start went stale as soon as another client stopped or restarted the listener through the plane. The plane now answers whenever it is served; the cached start answers only when no plane exists, since then nothing else can change the slot. Asking still never starts the plane. Closes #301
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the embedded transport,
interceptStatus()cached the result of the FFIrift_start_intercept, and only this handle's ownstopIntercept()cleared it. The C-ABI and the embedded admin plane share oneInterceptControlslot (rift#521, confirmed by the rift#1351 triage). So once another client stopped or restarted the listener through the plane, the cached status was stale:DELETE /intercepton the plane, the handle kept reporting the dead port;POST /intercept, it reported the old port.Changes
EmbeddedTransport.interceptStatus()reads the admin plane'sGET /interceptwhenever a plane is served. It uses the cached FFI start only when no plane exists, since nothing else can change the slot then. Asking does not start the plane.RiftImpl.intercept(InterceptOptions.attach())therefore no longer attaches to a dead port after a plane-side stop.Rift.interceptStatus()javadoc,docs/intercept.mdanddocs/design/sdk-api.mddrop the incorrect "two sources" description.Tests (
InterceptE2eIT)anFfiStartedListenerStoppedThroughTheAdminPlaneIsNoLongerReported: an FFI start, thenDELETE /intercepton the plane (204), and the status is empty.aListenerRestartedThroughTheAdminPlaneIsReportedWithItsNewPort: after the plane-side stop, another client restarts the listener, and the status shows the new port.anFfiStartAfterTheAdminPlaneIsServedIsReported: a regression pin for this handle's own start once a plane is served. It passed before the fix and is kept on purpose.Before the fix, the first two failed with stale ports (
expected: <55730> but was: <55727>;expected: <Optional.empty> but was: <Optional[InterceptStatus[port=55744 …]]>).Verification
RIFT_IT=1 ./mvnw -B -fae verifyon JDK 21, against the rift 0.22.0 corpus, dylib and binary: green. All 19InterceptE2eITtests pass.Follow-up
A related finding was filed as #316: after a plane-side stop, the handle's own
intercept()still refuses with "already started".Closes #301
🤖 Generated with Claude Code