#41 - Typo - NfQeueue - keyop-go/nfq_forwarder - Forgejo: Beyond coding. We Forge.

danny commented

2026-07-07 21:26:09 +01:00

(Migrated from gitlab.keyop.co.uk)

Somehow Claude has managed to introduce 'NfQeueue' as a typo in a few comments in ./internal/nfq_forwarder/nfq_forwarder.go
This is a spelling mistake.

This only appears to be in these comments and in CLAUDE.md, but should be rectified.

Somehow Claude has managed to introduce 'NfQeueue' as a typo in a few comments in ./internal/nfq_forwarder/nfq_forwarder.go This is a spelling mistake. This only appears to be in these comments and in CLAUDE.md, but should be rectified.

danny commented

2026-07-07 21:27:22 +01:00

(Migrated from gitlab.keyop.co.uk)

changed the description

danny commented

2026-07-07 21:32:02 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in merge request !73

claude commented

2026-07-08 06:02:11 +01:00

(Migrated from gitlab.keyop.co.uk)

Rechecked with both spellings - this isn't actually a typo of mine. NfQeueue is the real, exported verdict constant name in the third-party github.com/florianl/go-nfqueue@v1.3.2 library itself - a typo in that library, not something I introduced. Evidence, straight from the vendored module source on disk (~/go/pkg/mod/github.com/florianl/go-nfqueue@v1.3.2/types.go:158-165):

// Verdicts
const (
	NfDrop = iota
	NfAccept
	NfStolen
	NfQeueue
	NfRepeat
)

There is no NfQueue verdict constant exported by this library at all - code that tried to call nfqueue.NfQueue as a verdict simply wouldn't compile. Confirmed no newer version fixes this either: go list -m -versions github.com/florianl/go-nfqueue shows v1.3.2 (our pinned version) is the latest available.

What does exist, spelled correctly, is a completely different identifier in the same package: nfqueue.Config.NfQueue (a uint16 struct field - "which queue number to bind this listener to", used once in initNfqueue: NfQueue: uint16(conn.QueueNumber)). The two look almost identical at a glance (NfQueue the correctly-spelled config field for a queue number, vs NfQeueue the genuinely-misspelled-upstream verdict constant) - exactly why this is easy to mistake for a Claude-introduced error.

I grepped every .go and .md file in the repo for both spellings to be sure:

Every NfQeueue occurrence (in nfq_forwarder.go code/comments and CLAUDE.md) correctly refers to the verdict constant, matching the library's real (if misspelled) exported name.
The single NfQueue occurrence (nfq_forwarder.go:632) correctly refers to the unrelated Config.NfQueue field.

No inconsistency or genuine typo found either direction. I don't think there's a code or doc change needed here - happy to add an explicit comment calling out the "these look alike but are different identifiers" trap if that would help future readers, but wanted to confirm this finding with you first, given #41's premise turned out to be a very understandable but mistaken reading.

**Rechecked with both spellings - this isn't actually a typo of mine.** `NfQeueue` is the real, exported verdict constant name in the third-party `github.com/florianl/go-nfqueue@v1.3.2` library itself - a typo *in that library*, not something I introduced. Evidence, straight from the vendored module source on disk (`~/go/pkg/mod/github.com/florianl/go-nfqueue@v1.3.2/types.go:158-165`): ```go // Verdicts const ( NfDrop = iota NfAccept NfStolen NfQeueue NfRepeat ) ``` There is no `NfQueue` verdict constant exported by this library at all - code that tried to call `nfqueue.NfQueue` as a verdict simply wouldn't compile. Confirmed no newer version fixes this either: `go list -m -versions github.com/florianl/go-nfqueue` shows v1.3.2 (our pinned version) is the latest available. What *does* exist, spelled correctly, is a completely different identifier in the same package: `nfqueue.Config.NfQueue` (a `uint16` struct field - "which queue number to bind this listener to", used once in `initNfqueue`: `NfQueue: uint16(conn.QueueNumber)`). The two look almost identical at a glance (`NfQueue` the correctly-spelled config field for a queue *number*, vs `NfQeueue` the genuinely-misspelled-upstream verdict *constant*) - exactly why this is easy to mistake for a Claude-introduced error. I grepped every `.go` and `.md` file in the repo for both spellings to be sure: - Every `NfQeueue` occurrence (in `nfq_forwarder.go` code/comments and `CLAUDE.md`) correctly refers to the verdict constant, matching the library's real (if misspelled) exported name. - The single `NfQueue` occurrence (`nfq_forwarder.go:632`) correctly refers to the unrelated `Config.NfQueue` field. No inconsistency or genuine typo found either direction. I don't think there's a code or doc change needed here - happy to add an explicit comment calling out the "these look alike but are different identifiers" trap if that would help future readers, but wanted to confirm this finding with you first, given #41's premise turned out to be a very understandable but mistaken reading.

claude commented

2026-07-08 06:07:33 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in commit 893bb8b79046f7cbf8db8e147112a4a28beb5fbb

claude commented

2026-07-08 06:07:49 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in merge request !74

claude commented

2026-07-08 06:07:59 +01:00

(Migrated from gitlab.keyop.co.uk)

Added a clarifying comment at the one NfQueue (config field) usage in initNfqueue explaining it's a different identifier from the verdict constant NfQeueue used elsewhere. MR up for review: !74 (branch issue41_clarify_nfqueue_vs_nfqeueue).

Added a clarifying comment at the one `NfQueue` (config field) usage in `initNfqueue` explaining it's a different identifier from the verdict constant `NfQeueue` used elsewhere. MR up for review: !74 (branch `issue41_clarify_nfqueue_vs_nfqeueue`).

claude commented

2026-07-08 06:09:49 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in commit 3d67c563bc

mentioned in commit 3d67c563bcf07af652df2b7261feb30cedd199aa

danny commented

2026-07-08 06:27:10 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in commit b534e34d53

mentioned in commit b534e34d53a213f7c8a822c5b85080490431a807

danny (Migrated from gitlab.keyop.co.uk) closed this issue

2026-07-08 06:27:11 +01:00