Add V2FollowerController so /api/v2/followers/* is routed - #1626
Open
toddmitchell wants to merge 9 commits into
Open
Add V2FollowerController so /api/v2/followers/* is routed#1626toddmitchell wants to merge 9 commits into
toddmitchell wants to merge 9 commits into
Conversation
…ction Every message is prefixed "Preflight" for grepping. The important line is on the sender: one Information entry per not-ready recipient carrying the fields the recipient reported, so a failure can be diagnosed from the sender's own logs without access to the recipient's server. Ready outcomes stay at Debug to keep the volume down. The recipient logs its own refusal with a short greppable reason label (auto-connection-not-confirmed, permission-not-granted, caller-not-recognized, connection-needs-repair, not-configured, requires-upgrade) alongside the raw fields. Also raises two swallowed Debug logs to Warning -- an unusable local ICR and a failed caller-state lookup are both real faults that were invisible -- and an unexpected probe failure to Error. Refs #1613 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Preflight is advisory; a Ready result can still end in nothing happening later, and those phases were largely silent. - SendIntroductions logs recipients that could not be enqueued (Warning). - ReceiveIntroductions logs the new/already-connected/blocked breakdown, so "the introduction arrived but nothing happened" can be told apart from one that never arrived. Suppressing that detail matters only in the response to the introducer, not in our own logs. - SendOutstandingConnectionRequests logs each batch abandonment. That last one exposes an apparent bug left unchanged here: both skip conditions `break` rather than `continue`, so one already-connected or already-requested introducee abandons every remaining introduction in the batch, while the log message describes a per-recipient skip. Changing background-worker control flow is out of scope for this branch; the log now says how many were dropped. Refs #1613 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
No followers controller existed under UnifiedV2/, so every follow-related call from a v2 bearer-token client 404'd -- follow, unfollow, IdentitiesIFollow, followingme, IdentityIFollow and sync-feed-history. FollowerControllerBase was exposed on owner, app-v1 and guest only. V2FollowerController subclasses FollowerControllerBase for the same reason those three do: the actions and their route templates live on the base, so v2 stays in lockstep instead of drifting behind a second copy. Policy is OwnerOrApp -- the service asserts ManageFeed for follow/unfollow/sync, ReadWhoIFollow for the I-follow reads and ReadMyFollowers for the follower reads, none of which a guest carries on this surface. Adds V2FollowerClient / IFollowerHttpClientApiV2 and a FollowersHandle on OwnerSession, plus FollowerV2Tests covering follow -> list -> unfollow round trips across two identities and asserting explicitly that none of the seven routes returns 404. Fixes #1611 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Fixes #1611
What
There was no followers controller anywhere under
UnifiedV2/, so every follow-related call from a v2 bearer-token client 404'd.FollowerControllerBasewas exposed on owner, app-v1 and guest only.Adds
V2FollowerControllerat/api/v2/followers, plus theFollowersroute constant.All six routes the KMP feed client calls are now served, along with
GET /follower:FollowerServicePOST /api/v2/followers/followManageFeedPOST /api/v2/followers/unfollowManageFeedPOST /api/v2/followers/sync-feed-historyManageFeedGET /api/v2/followers/IdentitiesIFollowReadWhoIFollowGET /api/v2/followers/IdentityIFollowReadWhoIFollowGET /api/v2/followers/followingmeReadMyFollowersGET /api/v2/followers/followerReadMyFollowersDesign note
The controller subclasses
FollowerControllerBaserather than re-declaring the actions in the usual v2 style. The actions and their route templates live on the base, so this keeps v2 in lockstep with the owner/app/guest controllers instead of leaving a second copy to drift. Trade-off: inherited actions can't carry per-action[SwaggerOperation(Tags = ...)]like the other v2 controllers, so these land under the defaultV2Followertag.[ApiExplorerSettings(GroupName = "v2")]still puts them in the right Swagger doc, which is whatDocInclusionPredicatekeys on.Policy is
OwnerOrApp, per the issue.Tests
New
FollowerV2Tests(7 tests,Odin.Hosting.Tests.V2), driving two identities through the real perimeter follow flow:IdentitiesIFollowcontains the targetfollowingmecontains the followerIdentityIFollow/followerreturn the definition from each sidesync-feed-historysucceedsAllFollowerRoutes_AreRouted_AndDoNotReturnNotFound— asserts the regression itself, that none of the seven routes 404sSupporting test infra:
IFollowerHttpClientApiV2+V2FollowerClient(inOdin.Hosting.Tests/_V2/ApiClient/, alongside the other v2 clients) and aFollowersHandleonOwnerSession.New tests pass 7/7; the full
Odin.Hosting.Tests.V2project passes 418/418 (3 pre-existing skips).Not verified
The client-side call sites live in
homebase-id/chat-kmp/homebase-apiand were not exercised against this branch — route paths were matched against the table in #1611. ASP.NET routing is case-insensitive, so the mixed-case paths (IdentitiesIFollow,IdentityIFollow) resolve regardless of casing.🤖 Generated with Claude Code