{#if spec.commonExpositions.type == "INGRESS"} never matches, so the gRPC TLS properties are never rendered
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 58/100
Research direction
Read MicrocksConfigMapDependentResource/application.properties around line 135 and the related conditions fixed in issue #306. Then inspect MicrocksConfigMapDependentResourceTest and add positive and negative cases for the default INGRESS type; done means both gRPC TLS properties appear for INGRESS and are absent for another type. The issue is unclaimed and has no linked pull request, but it follows work on #306.
Written by the indexing model from the issue text.
Description
Describe the bug
In MicrocksConfigMapDependentResource/application.properties L135, the gRPC TLS properties are guarded by {#if spec.commonExpositions.type == "INGRESS"}. type is the ExpositionType enum, not a String, and in Qute an enum compared with a String literal is never equal. This is the same issue fixed for the Kafka authentication conditions in #306 (.type → .type.name). Since INGRESS is the default exposition type, this affects default installs.
Expected behavior
With commonExpositions.type: INGRESS, the generated application.properties contains grpc.server.certChainFilePath and grpc.server.privateKeyFilePath.
Actual behavior
The two lines are never rendered, whatever the exposition type.
How to Reproduce?
Render MicrocksConfigMapDependentResource.desired() with the default spec (commonExpositions.type: INGRESS) in a @QuarkusTest: neither line is present. With L135 changed to spec.commonExpositions.type.name == "INGRESS", both are rendered.
Microcks version or git rev
main @ 4d74e9f
Install method (docker-compose, helm chart, operator, docker-desktop extension,...)
operator
Additional information
Suggested fix: spec.commonExpositions.type.name == "INGRESS", plus a positive and a negative case in MicrocksConfigMapDependentResourceTest. As discussed in #306, I'm happy to send the PR.
AI disclosure: I used an AI assistant to help word this issue; I found the bug while working on #306 and checked it against main.
- Dominant language
- Java
- Stars
- 14
- Forks
- 13
- Avg merge
- 23m
- Merged PRs (30d)
- 3
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 microcks/microcks-operator
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
microcks/microcks-operator#332 · 1 comment ·
All issues in microcks/microcks-operator
Similar issues
-
Type: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
MCP add-on: JSON responses with non-ASCII characters are truncated (wrong Content-Length)Possibly taken @dhanushbs10 claimed this today. Openadd-on bug in:mcp
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
vaadin-map
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
vaadin/flow-components#10586 ·
Maintainers usually reply within 1 day
-
WeReadInstaller writes the launcher database on the main thread at handover (Activity pause timeout)Openbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
wpilibsuite/SystemcoreTesting#446 ·
Maintainers usually reply within 1 day