Repository navigation
Conversation
…ntics Aligns the router with the atlas chip-ingress write-service, addressing the review findings on #2861: - Publish (single event) now follows the write-service's all-or-nothing contract (atlas chip-ingress internal/server: Publish delegates to PublishCloudEvents with transaction_enabled=true): it fails the RPC when no subscribers are registered, when every forward fails, or when no subscriber accepts the event, and returns exactly one PublishResult on success. Previously it returned an empty PublishResponse with a nil error unconditionally, acking events that went nowhere. - Failure RPCs use codes.Internal, the write-service's failure code, in place of codes.Unavailable. - An empty batch short-circuits to a no-op success before the subscriber check, matching the write-service's empty-batch path. - The per-event detail merge is now order-independent and sized to the batch: a later subscriber's results can extend detail beyond the first provider's length (previously trailing events were acked with no detail), and a detail-less success (empty results, nil error) now accepts the whole batch, clearing other subscribers' rejections — the intent documented in #2861 but not enforced by its merge. Tests: single-event success/failure paths, empty batch, detail-less acceptance, merge extension past the first provider's detail, rejection surviving another subscriber's RPC failure; stub simplified to an immutable struct.
📊 API Diff Results
|
This branch has not been deployed
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.
Stacked on #2861 — implements the review findings so the chip-router matches the atlas chip-ingress write-service's behavior. Only the delta on top of #2861's head (
c69acae) is in this PR's diff.Changes
Reference: atlas
chip-ingressinternal/server/server.go/internal/service/write_service.go.Publish(single event) now matches the write-service's all-or-nothing contract. The write-service's single-event RPC delegates toPublishCloudEventswithtransaction_enabled=true: any failure returns a gRPC error, success returns exactly onePublishResult. The router previously returned&PublishResponse{}, nilunconditionally — acking events that went nowhere (the data-loss shape fix(chip-router): populate per-event PublishBatch results #2861 fixes forPublishBatch) and returning zero results on success. It now fails when no subscribers are registered, when every forward fails, or when no subscriber accepts the event, and returns one result on success.codes.Internal— the write-service's failure code (InternalError = status.Errorf(codes.Internal, "failed to publish events")) — in place ofcodes.Unavailableacross all failure paths. No node-side behavior change (the durable emitter retransmits on any error), but the router now speaks the same failure dialect as the write-service.Unavailablewith no subscribers).detailis now a fixed-length slice indexed by event position: a later subscriber's results can extend detail past the first provider's length (previously trailing events were acked with no detail), acceptance always wins over rejection, and a rejection only fills an empty slot. Also: a detail-less success (empty results, nil error) now accepts the whole batch, clearing other subscribers' rejections — the intent documented in fix(chip-router): populate per-event PublishBatch results #2861's comments but not enforced by its merge (a detail-less success + another subscriber's per-event rejection still reported the event rejected, even though it was delivered).Tests
go test -count=20 -race ./cmd/chip-router/— new coverage: single-event success (1 result) / no-subscribers / all-forwards-failed / all-rejected / detail-less acceptance overriding a rejection; empty-batch no-op; merge extension past the first provider's detail; a rejection surviving another subscriber's RPC failure;codes.Internalassertions. Stub simplified to an immutable struct (no mutex/counter).golangci-lint(repo config): 0 issues.