Skip to content

feat(sqs): --sqsFifoPartitionMap flag + parser + validator (Phase 3.D PR 4-A)#704

Merged
bootjp merged 3 commits intomainfrom
feat/sqs-htfifo-partition-map
Apr 29, 2026
Merged

feat(sqs): --sqsFifoPartitionMap flag + parser + validator (Phase 3.D PR 4-A)#704
bootjp merged 3 commits intomainfrom
feat/sqs-htfifo-partition-map

Conversation

@bootjp
Copy link
Copy Markdown
Owner

@bootjp bootjp commented Apr 28, 2026

Summary

Phase 3.D PR 4-A of the split-queue FIFO rollout. Operator-config foundation: parses --sqsFifoPartitionMap, validates against --raftGroups, plumbs through parseRuntimeConfig into runtimeConfig.sqsFifoPartitionMap. Stacks on top of #703 (PR 3, partitioned-keyspace constructors).

What's added

  • --sqsFifoPartitionMap flag with grammar queue.fifo:N=group_0,...,group_{N-1};...
  • parseSQSFifoPartitionMap + parseSQSFifoPartitionMapEntry (grammar + per-entry consistency)
  • validateSQSFifoPartitionMap (cross-check against --raftGroups)
  • sqsFifoQueueRouting struct (PartitionCount + Groups)
  • runtimeConfig.sqsFifoPartitionMap field

What's NOT added (deferred to PR 4-B)

  • Routing layer wiring through ShardedCoordinator
  • htfifo capability advertisement on /sqs_health
  • kv/lease_state.go leadership-refusal hook for non-htfifo binaries
  • Catalog polling for partitioned-queue discovery at startup

These are coupled by the design's "binary advertises htfifo only when both routing AND leadership-refusal are in place" rule, so they belong in one PR.

Validation coverage

  • PartitionCount > 0
  • PartitionCount ≤ 32 (per-queue cap)
  • PartitionCount must be a power of two
  • len(Groups) == PartitionCount
  • No duplicate queues across entries
  • Every named group exists in --raftGroups
  • Empty queue / empty group / trailing-comma / missing-= all rejected with the offending entry quoted in the error

Test plan

  • TestParseSQSFifoPartitionMap covers grammar, whitespace, multiple queues, all rejection paths.
  • TestValidateSQSFifoPartitionMap covers the missing-group case with queue + partition-index pointer.
  • parseRuntimeConfig integration: main_bootstrap_e2e_test.go updated for the new parameter.
  • go test -race ./adapter/... . pass.
  • golangci-lint ./... clean.

Self-review (per CLAUDE.md)

  1. Data loss — config-only change. No FSM, Pebble, or retention path is touched. No issue.
  2. Concurrency / distributed failures — single-shot parse at startup, no goroutines or shared state. No issue.
  3. Performance — startup-time validation only. No hot-path effect. No issue.
  4. Data consistency — partition count and group list must agree at parse time, so the runtime cannot see a half-shaped routing map. The flag has no effect on production traffic until PR 4-B + PR 5 land. No issue.
  5. Test coverage — 11 sub-tests in TestParseSQSFifoPartitionMap and 3 in TestValidateSQSFifoPartitionMap, covering every documented rejection branch.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 28, 2026

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9d1cb931-eb13-4d32-984e-90facc2b61f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/sqs-htfifo-partition-map

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the sqsFifoPartitionMap flag and associated logic to support HT-FIFO partition assignments. It includes a new routing structure, parsing logic for the flag's grammar, and validation against configured Raft groups. Unit tests have been added to ensure correct parsing and error handling. Feedback focuses on using the more idiomatic map[string]struct{} for set-based membership checks in the validation logic and tests.

Comment thread main.go Outdated
Comment on lines +492 to +495
groupsByName := make(map[string]string, len(groups))
for _, g := range groups {
groupsByName[strconv.FormatUint(g.id, 10)] = g.address
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The groupsByName map is only used for existence checks in validateSQSFifoPartitionMap. Using map[string]struct{} is more idiomatic and efficient as it clearly signals that only the keys matter.

Suggested change
groupsByName := make(map[string]string, len(groups))
for _, g := range groups {
groupsByName[strconv.FormatUint(g.id, 10)] = g.address
}
groupsByName := make(map[string]struct{}, len(groups))
for _, g := range groups {
groupsByName[strconv.FormatUint(g.id, 10)] = struct{}{}
}
References
  1. In Go, maps used as sets should use struct{} as the value type to save memory and clearly communicate intent that only keys are relevant. (link)

Comment thread shard_config.go Outdated
// raftGroupsByName is the {ID-as-string -> address} map produced by
// parseRaftGroups; the partition-map flag uses the same string IDs
// the operator supplied to --raftGroups so this lookup is direct.
func validateSQSFifoPartitionMap(m map[string]sqsFifoQueueRouting, raftGroupsByName map[string]string) error {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Update the signature to use map[string]struct{} to match the idiomatic membership check.

Suggested change
func validateSQSFifoPartitionMap(m map[string]sqsFifoQueueRouting, raftGroupsByName map[string]string) error {
func validateSQSFifoPartitionMap(m map[string]sqsFifoQueueRouting, raftGroupsByName map[string]struct{}) error {
References
  1. Using map[string]struct{} is the idiomatic way to implement a set in Go. (link)

Comment thread shard_config_test.go Outdated
m := map[string]sqsFifoQueueRouting{
"q.fifo": {PartitionCount: 2, Groups: []string{"g0", "g1"}},
}
groups := map[string]string{"g0": "127.0.0.1:1", "g1": "127.0.0.1:2"}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Update the test data to use map[string]struct{}.

Suggested change
groups := map[string]string{"g0": "127.0.0.1:1", "g1": "127.0.0.1:2"}
groups := map[string]struct{}{"g0": {}, "g1": {}}
References
  1. Using map[string]struct{} is the idiomatic way to implement a set in Go. (link)

Comment thread shard_config_test.go Outdated
Comment on lines +270 to +272
groups := map[string]string{
"g0": "a", "g1": "b", "g2": "c", "g3": "d",
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Update the test data to use map[string]struct{}.

Suggested change
groups := map[string]string{
"g0": "a", "g1": "b", "g2": "c", "g3": "d",
}
groups := map[string]struct{}{
"g0": {}, "g1": {}, "g2": {}, "g3": {},
}
References
  1. Using map[string]struct{} is the idiomatic way to implement a set in Go. (link)

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7c581f5a1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread main.go Outdated
}
groupsByName := make(map[string]string, len(groups))
for _, g := range groups {
groupsByName[strconv.FormatUint(g.id, 10)] = g.address
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Normalize group IDs consistently during map validation

buildSQSFifoPartitionMap keys groupsByName with strconv.FormatUint(g.id, 10), which canonicalizes IDs and drops any leading-zero formatting from --raftGroups. Because parseSQSFifoPartitionMap keeps group tokens as raw strings, a config like --raftGroups "01=a,02=b" with --sqsFifoPartitionMap "q.fifo:2=01,02" is rejected as “group not in --raftGroups” even though both groups exist. This introduces a startup-time false negative for valid operator input.

Useful? React with 👍 / 👎.

bootjp added 2 commits April 29, 2026 09:42
… PR 4-A)

Adds the operator-config foundation for HT-FIFO routing per §5 of the split-queue FIFO design. Stacks on top of PR 3 (#703), which lands the partitioned-keyspace constructors.

The grammar matches the design: 'queue.fifo:N=group_0,...,group_{N-1};...' with multiple queue entries separated by ';' (commas are reserved for the per-queue group list). PartitionCount must be a power of two ≤ 32 — the validator rejects anything else at config-parse time so a typo cannot land a half-shaped routing map at runtime.

Two-stage validation:
- parseSQSFifoPartitionMap: grammar + per-entry consistency (PartitionCount agrees with len(Groups), partition count is a power of two within the cap, no duplicate queues).
- validateSQSFifoPartitionMap: runs after --raftGroups is parsed and asserts every group named in the partition map exists in --raftGroups; rejects with a queue/partition-pointer error message so the operator can fix typos without re-counting.

Plumbed through parseRuntimeConfig into runtimeConfig.sqsFifoPartitionMap. Not yet consumed by routing — PR 4-B will wire it through ShardedCoordinator and add the htfifo capability advertisement once the routing layer lands. The §11 PR 2 dormancy gate still rejects PartitionCount > 1 on CreateQueue, so populating this flag has no effect on production traffic until PR 5 lifts the gate atomically with the data-plane fanout.

parseSQSFifoPartitionMapEntry was extracted into parseSQSFifoPartitionCount + parseSQSFifoGroupList helpers to stay under the cyclop=10 ceiling once the four-rejection validation surface landed (zero / over-cap / non-power-of-2 / count-mismatch). parseRuntimeConfig grew over the cyclop ceiling too, so the partition-map block was extracted into buildSQSFifoPartitionMap.

Tests in shard_config_test.go cover:
- Empty input yields empty map.
- Single-queue happy path.
- Multiple queues separated by ';'.
- Whitespace trimming.
- PartitionCount > 0 enforcement.
- PartitionCount must be a power of two.
- PartitionCount within the per-queue cap.
- count and group-list length must agree.
- Malformed entry (missing '=', empty queue, empty group, trailing comma).
- Duplicate queue rejection.
- validateSQSFifoPartitionMap: all-groups-present passes; missing group fails with queue + partition-index pointer in the error message.

go test -race ./... pass; golangci-lint ./... clean. No behaviour change in production paths.
Two review-driven fixes folded into one commit:

1) Codex P2 (group ID normalization)

parseRaftGroups runs each --raftGroups entry through strconv.ParseUint
and the validator keys its set off strconv.FormatUint(g.id, 10) — so
the canonical form drops leading zeros ("01" → "1"). The partition
map parser kept group tokens as raw strings, which made
--raftGroups "01=a,02=b" with --sqsFifoPartitionMap "q.fifo:2=01,02"
fail validation as group-not-found even though both groups exist.

parseSQSFifoGroupList now ParseUint+FormatUints each group reference
at parse time, which:
  - rejects non-numeric group references early with a clear pointer
    ("group %q is not a uint64 ID") instead of letting them fall through
    to a later group-not-found error,
  - aligns the partition-map shape with parseRaftGroups so the validator
    is a plain set-membership check.

2) Gemini medium (idiomatic set type)

validateSQSFifoPartitionMap took map[string]string but only used the
keys. Switch the parameter and the buildSQSFifoPartitionMap caller to
map[string]struct{} — the address half was unused, the new signature
makes set-only-keys intent visible, and the test data sites use the
same shape.

Tests:
  - new sub-test "normalizes leading-zero group IDs" pins the codex case
  - new sub-test "rejects non-uint64 group reference" pins the parse-time
    rejection of alphabetic group names
  - existing sub-tests reshaped to use numeric group IDs (consistent
    with what parseRaftGroups actually accepts on the operator side)
  - validator tests use map[string]struct{} for the canonical-ID set
@bootjp bootjp force-pushed the feat/sqs-htfifo-partition-map branch from 7c581f5 to 050a9af Compare April 29, 2026 00:46
@bootjp
Copy link
Copy Markdown
Owner Author

bootjp commented Apr 29, 2026

@claude review

Round 2 — addresses gemini-code-assist + codex review:

  • Codex P2 (group ID canonicalization): parseRaftGroups runs each --raftGroups entry through ParseUint and the validator keys its set off FormatUint, dropping leading zeros ("01" → "1"). The partition-map parser kept group tokens raw, so --raftGroups "01=a,02=b" with --sqsFifoPartitionMap "q.fifo:2=01,02" failed validation as group-not-found even though both groups exist. parseSQSFifoGroupList now ParseUint+FormatUints each token at parse time — also rejects non-numeric group references early with a clear pointer ("group %q is not a uint64 ID") instead of letting them fall through to group-not-found.
  • Gemini medium (idiomatic set type): validateSQSFifoPartitionMap signature switched from map[string]string to map[string]struct{} — only keys were used. buildSQSFifoPartitionMap and the test data updated to match.

New sub-tests pin the codex case ("normalizes leading-zero group IDs") and the parse-time rejection ("rejects non-uint64 group reference"). Existing sub-tests reshaped to use numeric group IDs (consistent with what parseRaftGroups actually accepts).

Also rebased onto the latest tip of feat/sqs-htfifo-keyspace (PR 703) to pick up the partitioned-key delimiter fix from gemini's PR 703 review.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 29, 2026

Claude finished @bootjp's task in 2m 29s —— View job


Review — Round 2

  • Read changed files (main.go, shard_config.go, shard_config_test.go, main_bootstrap_e2e_test.go)
  • Verify Round 2 fixes (group ID canonicalization, idiomatic set type)
  • Check edge cases and error paths
  • Review test coverage

Both Gemini and Codex feedback items are correctly addressed. Overall this is a clean round 2 — no blocking issues. A few minor observations below.

What's well done

Group ID canonicalization (shard_config.go:262–293): parseSQSFifoGroupList correctly does the ParseUint → FormatUint round-trip on each group token. This means "01""1" at parse time, so the validator's lookup against the map[string]struct{} set (keyed by FormatUint in buildSQSFifoPartitionMap) always lines up. Early rejection of non-numeric strings with "group %q is not a uint64 ID" is clearer than letting them fall through to group-not-found.

Idiomatic set type (shard_config.go:305–318): validateSQSFifoPartitionMap takes map[string]struct{} with a plain _, ok := raftGroupIDs[group] check. buildSQSFifoPartitionMap (main.go:477–504) builds the set correctly via strconv.FormatUint(g.id, 10), so both sides agree on canonical form.

Cyclop decomposition: Three helpers (parseSQSFifoPartitionMapEntry, parseSQSFifoPartitionCount, parseSQSFifoGroupList) keep each function under the cyclomatic ceiling while preserving the full entry string for error messages. The comments explaining the extractions are concise and accurate.

Test coverage: 13 sub-tests total; the two new ones ("normalizes leading-zero group IDs", "rejects non-uint64 group reference") directly pin the codex case and the parse-time rejection. All existing sub-tests now use numeric group IDs, which is consistent with what parseRaftGroups actually accepts.


Minor observations

1. Awkward error message in parseSQSFifoPartitionCount (shard_config.go:229–232)

"%q: PartitionCount %q is not a non-negative integer"

strconv.ParseUint rejects any non-digit character, including a leading -. "Non-negative integer" is technically true (uint means ≥ 0) but sounds odd in context since the intent is "must be a positive decimal integer". A phrasing like "is not a valid unsigned integer" or "must be a positive decimal integer" communicates the constraint more directly. Low priority.

2. Exported fields on unexported struct (shard_config.go:54–57)

type sqsFifoQueueRouting struct {
    PartitionCount uint32
    Groups         []string
}

sqsFifoQueueRouting is package-internal but its fields are exported. Go convention for package-private types is to use unexported fields to prevent accidental reflective access if the type is ever exported later. partitionCount / groups would be more idiomatic. Harmless as-is, but worth aligning. Fix this →

3. Non-deterministic queue order in validateSQSFifoPartitionMap error messages (shard_config.go:307)

for queue, routing := range m {

Go map iteration is non-deterministic. For a config with two misconfigured queues, the error message references whichever queue Go picks on that run. This is cosmetic for startup validation (not a race condition, just which queue is reported first may vary), but if operator UX matters later, sorting the keys before iteration makes errors reproducible:

queues := slices.Sorted(maps.Keys(m))
for _, queue := range queues {
    routing := m[queue]
    ...

Low priority for a startup-time validator, but worth noting.

4. Unreachable "empty queue name" branch for colon-at-position-zero input (shard_config.go:200–207)

For :2=1,2, colonIdx == 0 triggers the structural check (colonIdx <= 0) before the queue == "" branch is ever evaluated. The empty-queue-name check only fires when colonIdx > 0 but the slice entry[:colonIdx] trims to "" (e.g., " :2=1,2"colonIdx=1, trimmed queue=""). Both branches produce the same error sentinel, so behavior is correct. Just noting the unreachable path for future readers.


Summary

Both review items are properly addressed. The canonicalization logic is correct and well-tested, the set type is idiomatic, and the new test cases pin exactly the cases the reviewers raised. Items 1–4 above are all minor polish, not correctness concerns. No blocking issues.

Addresses three minor observations from the round 2 Claude review.
Each is informational rather than blocking, but they tighten the
parser's UX and the package-internal style.

1) Reword PartitionCount-not-an-integer error

  before: "PartitionCount %q is not a non-negative integer"
  after:  "PartitionCount %q must be a positive decimal integer"

  uint64 narrowing rules out negatives anyway, so the original phrasing
  led with the wrong constraint. The new phrasing matches what the
  parser actually requires.

2) Lowercase fields on the unexported sqsFifoQueueRouting

  PartitionCount → partitionCount
  Groups         → groups

  The struct is package-internal; exported field names invite
  reflective access if it's ever surfaced and contradict the rest of
  shard_config.go's style (groupSpec, rangeSpec both use lowercase
  fields). All call sites in shard_config.go and shard_config_test.go
  updated.

3) Sort queue keys in validateSQSFifoPartitionMap iteration

  Go map iteration is randomised, so a config with two misconfigured
  queues reports a different queue on each run. Sorting via
  slices.Sorted(maps.Keys(m)) makes the validator's error
  reproducible for operator triage and for any future golden-test
  assert that pins the failure message.
@bootjp
Copy link
Copy Markdown
Owner Author

bootjp commented Apr 29, 2026

@claude review

Round 3 — minor polish from the round 2 review:

  1. Error wording: "PartitionCount %q is not a non-negative integer" → "PartitionCount %q must be a positive decimal integer". uint64 narrowing already excludes negatives.
  2. Lowercase fields on unexported struct: sqsFifoQueueRouting.PartitionCountpartitionCount, Groupsgroups. Aligns with groupSpec / rangeSpec in the same file. Call sites in shard_config.go and shard_config_test.go updated.
  3. Deterministic validator iteration: validateSQSFifoPartitionMap now sorts queue keys via slices.Sorted(maps.Keys(m)) before iterating, so a config with multiple misconfigured queues always reports the lexicographically-first failure rather than a randomised one.

Item 4 from the review (the unreachable-path note about :2=1,2 hitting colonIdx <= 0 first) is informational only — both branches return the same sentinel, so behavior is correct. Left as-is per the reviewer's note.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 29, 2026

Claude finished @bootjp's task in 1m 4s —— View job


Review — Round 3

  • Read changed files (shard_config.go, shard_config_test.go, main.go, main_bootstrap_e2e_test.go)
  • Verify Round 3 changes (error wording, lowercase fields, deterministic iteration)
  • Check correctness of slices.Sorted(maps.Keys(m)) usage
  • Verify all call sites updated for field renames
  • Final review summary

All three items from the Round 2 review are correctly addressed. No blocking issues.

What's well done

1. Error wording (shard_config.go:229): "must be a positive decimal integer" is clear and accurate — strconv.ParseUint is documented as accepting positive decimal integers, so this wording is exact rather than the previous "non-negative integer" which undersold the constraint. ✓

2. Lowercase fields (shard_config.go:54–57): sqsFifoQueueRouting.partitionCount and .groups now follow Go convention for package-private types. All call sites are updated consistently:

  • parseSQSFifoPartitionMapEntry at shard_config.gosqsFifoQueueRouting{partitionCount: count, groups: groups}
  • validateSQSFifoPartitionMaprouting.groups
  • shard_config_test.gosqsFifoQueueRouting{partitionCount: 8, groups: ...} and .partitionCount, .groups field accesses ✓

3. Deterministic iteration (shard_config.go:307): slices.Sorted(maps.Keys(m)) is the correct idiom for Go 1.23+ (project targets Go 1.25). maps.Keys returns an iter.Seq[string] and slices.Sorted consumes it and returns a sorted slice — this compiles correctly and behaves correctly on a nil map (nil map keys → empty iterator → empty slice → no loop iterations), which is why the "empty map passes" test passes nil for both args without special-casing.

4. Import additions (shard_config.go:4–5): "maps" and "slices" added correctly. No unused imports.

5. e2e test (main_bootstrap_e2e_test.go:343): parseRuntimeConfig call updated with the extra empty sqsFifoPartitionMapRaw argument. ✓

One minor note (non-blocking)

In the "trims whitespace" test, the outer whitespace in " orders.fifo : 2 = 1 , 2 " exercises the strings.TrimSpace in parseSQSFifoPartitionMap's entry loop, but the spaces around : and = are trimmed via entry[colonIdx+1:eqIdx]parseSQSFifoPartitionCount's internal TrimSpace and entry[eqIdx+1:]parseSQSFifoGroupList's internal TrimSpace. The test correctly validates the end result (["1", "2"]) but does not assert that m["orders.fifo"].partitionCount == 2. Minor omission — the count is implicitly confirmed by the parse succeeding, but an explicit require.Equal(t, uint32(2), m["orders.fifo"].partitionCount) would be more complete. Not worth a round-trip.

Summary

Round 3 is clean. All four Round 2 observations that warranted action are addressed. Item 4 (unreachable-path note) is intentionally left as-is per the reviewer's note — the sentinel is the same regardless of which branch fires, so behavior is correct.

Base automatically changed from feat/sqs-htfifo-keyspace to main April 29, 2026 01:04
@bootjp bootjp merged commit d4d7ad8 into main Apr 29, 2026
5 checks passed
@bootjp bootjp deleted the feat/sqs-htfifo-partition-map branch April 29, 2026 01:04
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5d7cb96ce1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread shard_config.go
Comment on lines +206 to +210
queue := strings.TrimSpace(entry[:colonIdx])
if queue == "" {
return "", sqsFifoQueueRouting{}, errors.Wrapf(ErrInvalidSQSFifoPartitionMapEntry,
"%q: empty queue name", entry)
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Enforce .fifo suffix in partition-map queue names

The parser documents the entry shape as queue.fifo:N=... but only checks for a non-empty queue token, so inputs like orders:2=1,2 are accepted as valid. This creates a silent misconfiguration path where a typo in the queue name passes startup validation even though it violates the advertised grammar, making operators think partition routing is configured when it is not. Please validate the queue token ends with .fifo in parseSQSFifoPartitionMapEntry.

Useful? React with 👍 / 👎.

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