Skip to content

fix: remove duplicate wrong error log in socket/fetch and dead code in reliablePing#370

Open
immanuwell wants to merge 1 commit into
fosrl:mainfrom
immanuwell:fix/docker-fetch-duplicate-log-and-reliable-ping-dead-code
Open

fix: remove duplicate wrong error log in socket/fetch and dead code in reliablePing#370
immanuwell wants to merge 1 commit into
fosrl:mainfrom
immanuwell:fix/docker-fetch-duplicate-log-and-reliable-ping-dead-code

Conversation

@immanuwell
Copy link
Copy Markdown

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Description

Two small bugs fixed:

1. Wrong log message in newt/socket/fetch handler (main.go)

After client.SendMessage("newt/socket/containers", ...) there were two back-to-back if err != nil checks on the same var. The first one had a copy-pasted message from a different handler: "Failed to send registration message" -- totally wrong context. On any send error you'd see that bogus line logged first, then the correct one right after. Dropped the duplicate stale block, kept the one with the right message.

2. Dead code in reliablePing (common.go)

successCount starts at 0 and is only incremented once before the if successCount > 0 guard -- so that condition is always true when reached. The function always returned there, making everything after the loop unreachable. Removed the always-true guard and the dead post-loop code, left the behavior identical.

How to test?

Bug 1 -- check the newt/socket/fetch handler in main.go. With the old code, any error from client.SendMessage would log "Failed to send registration message" (wrong) followed by "Failed to send Docker container list" (right). Now only the correct line fires.

Bug 2 -- static analysis or a quick read: successCount++ immediately before if successCount > 0 guarantees the condition, making the post-loop if successCount == 0 branch and final return unreachable. Behavior is unchanged, code is just honest now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant