Kafka sidecar: add a test for the record → CloudEvent → ack delivery path
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with pkg/keda and TestInt_KafkaScaling to see how the existing integration test sets up Kafka and verifies partition assignment. Then inspect the injected Kafka runtime sidecar’s delivery path and determine whether the test belongs in the slim Kafka job or knative-extensions/func-adapter-kafka. Done means testing CloudEvent delivery and offset commits after a 2xx, plus retry without commit after a non-2xx.
Written by the indexing model from the issue text.
Description
What
There is no test asserting the actual record → CloudEvent → ack delivery path
through the injected Kafka runtime sidecar.
Gap
The KEDA integration test (pkg/keda, TestInt_KafkaScaling) only verifies
readiness = partition assignment; it produces no records. So the real path —
consume a record → build a CloudEvent → POST to the function's HTTP server →
2xx → commit offset — is unverified from the func side. The negative case
(a non-2xx response must not commit the offset) is also untested.
Proposal
Add a test that produces a record and asserts:
- the function receives the expected CloudEvent,
- the offset is committed after a 2xx, and
- the offset is not committed on a non-2xx (the record is retried).
This could live as an integration test on the slim Kafka job, or as a focused
test in knative-extensions/func-adapter-kafka.
/kind cleanup
Follow-up to #4060.
- Dominant language
- Go
- Stars
- 365
- Forks
- 224
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from knative/func
-
kind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
KEDA deployer: default minReplicaCount prevents scale-to-zeroPossibly taken @Tushar-Khandelwal-2004 claimed this 113 days ago. Openlifecycle/stale
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
knative/func#3924 · 1 comment ·
Maintainers usually reply within 1 day
-
git/gitlab: default project webhooks to SSL verification when creating hooksPossibly taken @Vi-shub claimed this 159 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
mcp: config add/remove handlers bypass readonly guardPossibly taken @Elvand-Lie claimed this 162 days ago. Openkind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
knative/func#3704 · 1 comment ·
Maintainers usually reply within 1 day
-
kind/bug
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
Similar issues
-
usage: a custom provider's balance meters ("…%" in the balance path) ignore the Left/Used switchOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug iam-service
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
platform-mesh/platform-mesh#425 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
grafana/tempo-operator#1691 ·
Maintainers usually reply within 1 day
-
fix: presentation.go with mcp-table.go: the message for each MCP server comes backPossibly taken @mge1512 claimed this today. Openbug
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
mark3labs/kit#242 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
slavakurilyak/awesome-ai-agents#827 ·
Maintainers usually reply within 1 day