#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

claude commented

2026-07-08 06:28:35 +01:00

(Migrated from gitlab.keyop.co.uk)

Merged via !74 (merge commit b534e34). No release for this one - a comment-only clarification, per Danny.

Merged via !74 (merge commit `b534e34`). No release for this one - a comment-only clarification, per Danny.

danny commented

2026-07-09 22:07:32 +01:00

Owner

For reference, Issue https://github.com/florianl/go-nfqueue/issues/112 has been raised on the upstream project to notify the author of the original minor error.

danny commented

2026-07-11 18:08:16 +01:00

Owner

Upstream issue https://github.com/florianl/go-nfqueue/issues/112 and I provided a PR to resolve the typo. This should be resolved in the main branch now but may not make it to a release for a while.

Re-opening this issue in order to remember to check for the updated upstream, and adjust our code to use it when available.

Upstream issue https://github.com/florianl/go-nfqueue/issues/112 and I provided a PR to resolve the typo. This should be resolved in the main branch now but may not make it to a release for a while. Re-opening this issue in order to remember to check for the updated upstream, and adjust our code to use it when available.

danny reopened this issue

2026-07-11 18:08:16 +01:00

claude commented

2026-07-14 18:45:48 +01:00

Collaborator

Checked upstream just now:

Latest tagged v1.x release is v1.3.3 (2026-07-11) - still has the NfQeueue typo, no NfQueue alias. So the fix hasn't made it into a release yet, confirming what you said.
The unreleased v1.x main branch does have your fix: correctly-spelled NfQueue as the real constant, plus NfQeueue kept as a deprecated alias (// Deprecated: Please migrate to NfQueue.) for compatibility.
There's also a separate v2 module line (github.com/florianl/go-nfqueue/v2, currently at v2.1.0) - unrelated pre-existing major version bump, not connected to this fix. It still has the typo too (no NfQueue alias there either), so it's not a shortcut to the fix.
Upstream issue #112 is closed as of 2026-07-11.

Nothing to upgrade to yet - leaving this open as a reminder per your comment. Will pick it back up once a v1.3.4+ (or later) release actually ships with the fix, then swap our NfQeueue usages over to NfQueue and bump the go.mod pin.

Checked upstream just now: - Latest tagged v1.x release is **v1.3.3** (2026-07-11) - still has the `NfQeueue` typo, no `NfQueue` alias. So the fix hasn't made it into a release yet, confirming what you said. - The unreleased v1.x `main` branch does have your fix: correctly-spelled `NfQueue` as the real constant, plus `NfQeueue` kept as a deprecated alias (`// Deprecated: Please migrate to NfQueue.`) for compatibility. - There's also a separate `v2` module line (`github.com/florianl/go-nfqueue/v2`, currently at v2.1.0) - unrelated pre-existing major version bump, not connected to this fix. It still has the typo too (no `NfQueue` alias there either), so it's not a shortcut to the fix. - Upstream issue #112 is closed as of 2026-07-11. Nothing to upgrade to yet - leaving this open as a reminder per your comment. Will pick it back up once a v1.3.4+ (or later) release actually ships with the fix, then swap our `NfQeueue` usages over to `NfQueue` and bump the `go.mod` pin.

claude added the

On Hold

label

2026-07-14 18:48:00 +01:00

claude commented

2026-07-14 18:48:18 +01:00

Collaborator

Putting this on hold for now. Summary of what's needed to close it out, for whoever picks it back up:

Next action: periodically check https://github.com/florianl/go-nfqueue/releases (or run go list -m -versions github.com/florianl/go-nfqueue) for a new v1.x tag beyond the current v1.3.3. As of 2026-07-10, v1.3.3 does not contain Danny's upstream fix - only the unreleased v1.x main branch does.

Once a release with the fix ships:

Bump the github.com/florianl/go-nfqueue pin in go.mod/go.sum to that version.
Swap every use of the misspelled verdict constant nfqueue.NfQeueue in this codebase over to the now-correctly-spelled nfqueue.NfQueue (the old spelling will remain available as a deprecated alias upstream, but we should migrate off it, not just keep building against the deprecated name).
Update the corresponding comments in internal/nfq_forwarder/nfq_forwarder.go and CLAUDE.md that currently explain the NfQeueue/NfQueue confusion (see setVerdict's doc comment and initNfqueue's NfQueue config-field comment) - once the constant itself is spelled correctly, those comments explaining the confusion become unnecessary/stale and should be simplified or removed.
Note there's also an unrelated v2 module line (github.com/florianl/go-nfqueue/v2) - do not confuse this with the fix; as of v2.1.0 it still has the typo and has no connection to Danny's patch.

No code changes needed right now - just re-check upstream periodically.

Putting this on hold for now. Summary of what's needed to close it out, for whoever picks it back up: **Next action**: periodically check https://github.com/florianl/go-nfqueue/releases (or run `go list -m -versions github.com/florianl/go-nfqueue`) for a new v1.x tag beyond the current v1.3.3. As of 2026-07-10, v1.3.3 does *not* contain Danny's upstream fix - only the unreleased v1.x `main` branch does. **Once a release with the fix ships**: 1. Bump the `github.com/florianl/go-nfqueue` pin in `go.mod`/`go.sum` to that version. 2. Swap every use of the misspelled verdict constant `nfqueue.NfQeueue` in this codebase over to the now-correctly-spelled `nfqueue.NfQueue` (the old spelling will remain available as a deprecated alias upstream, but we should migrate off it, not just keep building against the deprecated name). 3. Update the corresponding comments in `internal/nfq_forwarder/nfq_forwarder.go` and `CLAUDE.md` that currently explain the `NfQeueue`/`NfQueue` confusion (see `setVerdict`'s doc comment and `initNfqueue`'s `NfQueue` config-field comment) - once the constant itself is spelled correctly, those comments explaining the *confusion* become unnecessary/stale and should be simplified or removed. 4. Note there's also an unrelated `v2` module line (`github.com/florianl/go-nfqueue/v2`) - do not confuse this with the fix; as of v2.1.0 it still has the typo and has no connection to Danny's patch. No code changes needed right now - just re-check upstream periodically.

Rows
Columns

Typo - NfQeueue #41