Repository navigation
Consume CAN traffic during client startup - #32
Merged
Merged
Conversation
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.
High-volume CAN traffic could overflow Beacon's 256-message receive buffer while the blocking n2k constructor completed address claiming. Beacon then reconnected and repeated the same startup window.
Upgrade to n2k v1.8.0 and register a scanner with
NewUnstartedClientbefore callingStart. A receive worker drains traffic throughout transport readiness and address claiming; the endpoint becomesuponly after startup succeeds. Failed startup closes and joins the receiver, and shutdown cancels pending discovery requests before waiting for them. PGN-list requests wait until the client can transmit.The dependency upgrade also updates renamed PGN/manufacturer constants and adapts the device-function lookup while preserving unknown-name fallbacks. Existing buffer sizes and overflow behavior remain unchanged; sustained consumer lag can still overflow a subscriber.
Regression coverage delivers 1,024 messages through the existing 256-message buffer during both transport readiness and address claiming, verifies continued delivery on the same connection, checks discovery-request timing, and confirms that last-handle release interrupts startup.
Validation passed:
go test ./... -timeout 300sgo test -race ./... -timeout 300sgo vet ./...just lintjust secureCGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build ./...git diff --checkHardware, browser, and Linux vessel resource gates were not run locally. No deployment was performed.