Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: sentence-count-guardrail counts whitespace-only segments in the buffered path but not in the streaming path, so the same text can pass one and fail the other

Open Beginner friendly
#3,885 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
api

Research direction

The issue points to policies/sentence-count-guardrail/sentencecountguardrail.go in wso2/gateway-controllers, where validatePayload and countSentences split and count segments differently. Read those functions and the existing tests, then add a case for One. . Two. that exercises both paths. Done when both paths report the same sentence count and the test passes.

Written by the indexing model from the issue text.

Description

Aspect/API Severity/Minor Type/Bug
Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

The sentence-count-guardrail policy (wso2/gateway-controllers, policies/sentence-count-guardrail/sentencecountguardrail.go, policy version v1.0.2) splits text on [.!?] in two places and counts the non-empty pieces differently:

  1. Buffered path (validatePayload, used for normal JSON request/response bodies): counts a segment when s != "". A segment that is only spaces still counts.
  2. Streaming / SSE path (countSentences, used by NeedsMoreResponseData and OnResponseBodyChunk): counts a segment when strings.TrimSpace(s) != "". A segment that is only spaces does not count.

So the text One. . Two. is 3 sentences on the buffered path and 2 sentences on the streaming path. With min = max = 2, a non-streaming request is rejected with HTTP 422 while the same content streamed as SSE is accepted. Operators cannot rely on the thresholds meaning the same thing for stream: false and stream: true.

This is separate from counting abbreviations such as p.m. (reported in the closed #2500). Here the two code paths disagree with each other on the same punctuation rules.

Note: filed in wso2/api-platform because wso2/gateway-controllers, where the policy lives, has issues disabled.

Steps to Reproduce

On wso2/gateway-controllers main c5d83e0, add this test under policies/sentence-count-guardrail and run go test -run TestZZCountPaths -v ..

func TestZZCountPaths(t *testing.T) {
	for _, text := range []string{"One. Two.", "One. . Two.", "One.  . Two."} {
		cStream := countSentences(text)
		sentences := sentenceSplitRegexCompiled.Split(text, -1)
		cBuffered := 0
		for _, s := range sentences {
			if s != "" {
				cBuffered++
			}
		}
		fmt.Printf("text=%q countSentences=%d validatePayloadStyle=%d\n", text, cStream, cBuffered)
	}
	p := &SentenceCountGuardrailPolicy{}
	body := []byte(`{"messages":[{"content":"One. . Two."}]}`)
	r := p.validatePayload(body, SentenceCountGuardrailPolicyParams{
		Min: 2, Max: 2, JsonPath: "$.messages[-1].content", ShowAssessment: true,
	}, false)
	fmt.Printf("validatePayload -> %T status=%v\n", r, r.(policy.ImmediateResponse).StatusCode)
	fmt.Printf("countSentences=%d\n", countSentences("One. . Two."))
}

Expected behavior

Both paths report the same count for the same text. With min = max = 2, either both accept One. . Two. or both reject it.

Actual behavior

text="One. Two." countSentences=2 validatePayloadStyle=2
text="One. . Two." countSentences=2 validatePayloadStyle=3
text="One.  . Two." countSentences=2 validatePayloadStyle=3
validatePayload -> policy.ImmediateResponse status=422
countSentences=2
Severity Level of the Issue

Severity/Minor (Non-critical functionality. Can be fixed in future releases)

Environment Details (with versions)
  • wso2/gateway-controllers main c5d83e0 (sentence-count-guardrail v1.0.2, sdk/core v0.3.4)
  • Go 1.27.2, Debian Linux x86_64
Dominant language
Go
Stars
79
Forks
130
Avg merge
2d 2h
Merged PRs (30d)
165

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wso2/api-platform

All issues in wso2/api-platform

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.