test(it): add template rendering IT coverage for LlmProvider, LlmProxy, Mcp#1829
test(it): add template rendering IT coverage for LlmProvider, LlmProxy, Mcp#1829renuka-fernando wants to merge 1 commit intowso2:mainfrom
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughTemplate Rendering Integration Test Coverage ExtensionThis PR extends template-rendering integration test coverage to include LlmProvider, LlmProxy, and Mcp artifact types alongside existing RestApi coverage. Key Changes
Overall, this PR broadens template-rendering IT coverage to additional artifact kinds and centralizes DB assertion and retry logic to support those scenarios. WalkthroughThis pull request generalizes template configuration handling across multiple artifact kinds. It adds GetStoredSourceConfigurationWithRetry as a reusable bounded-retry DB helper and updates GetStoredRestAPISourceConfigurationWithRetry to delegate to it. Test step bindings are generalized to accept artifact kinds (RestApi, LlmProvider, LlmProxy, Mcp), map them to storage tables, and verify persisted source configuration via the new helper. Three end-to-end feature scenarios were added to validate that secret/env template expressions are persisted unrendered and resolved at runtime. Sequence Diagram(s)sequenceDiagram
participant Client as Test Client
participant Gateway as Gateway
participant DB as Persisted Configuration
participant Upstream as Upstream Service / Tool
Client->>Gateway: runtime request (API or MCP)
Gateway->>DB: read stored source configuration (unrendered templates)
DB-->>Gateway: stored config (unrendered)
Gateway->>Upstream: resolve templates (secret/env) -> send resolved headers/URL
Upstream-->>Gateway: response
Gateway-->>Client: response (assert runtime result)
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.1)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain modules listed in go.work or their selected dependencies" Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
gateway/it/steps_template.go (1)
48-59: ⚡ Quick winKeep supported artifact kinds in one source of truth.
The supported-kind list is currently repeated in the step regex,
kindTables, and the error string. Consider deriving the regex and supported-kinds message fromkindTablesto avoid drift when adding/removing kinds.Also applies to: 101-104
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@gateway/it/steps_template.go` around lines 48 - 59, The step definition hardcodes the supported kinds in the regex and error messages; instead derive them from the kindTables map so there is a single source of truth. Change the ctx.Step registration that invokes storedConfigurationShouldContain to build its allowed-kind pattern from the keys of kindTables (e.g., join keys with |) or make the regex accept any kind and validate inside storedConfigurationShouldContain against kindTables; also replace any error message that lists supported kinds to generate that message from kindTables keys so additions/removals only need to change kindTables.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@gateway/it/steps_template.go`:
- Around line 48-59: The step definition hardcodes the supported kinds in the
regex and error messages; instead derive them from the kindTables map so there
is a single source of truth. Change the ctx.Step registration that invokes
storedConfigurationShouldContain to build its allowed-kind pattern from the keys
of kindTables (e.g., join keys with |) or make the regex accept any kind and
validate inside storedConfigurationShouldContain against kindTables; also
replace any error message that lists supported kinds to generate that message
from kindTables keys so additions/removals only need to change kindTables.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2d2a91c6-1e6e-4471-851f-5e12c0fcdb0d
📒 Files selected for processing (3)
gateway/it/db_helpers.gogateway/it/features/template-functions.featuregateway/it/steps_template.go
…y, Mcp
Extend template-rendering integration tests beyond RestApi to cover LlmProvider,
LlmProxy, and Mcp. Each scenario validates the render contract: API responses and
DB storage preserve unrendered template expressions ({{ secret }}, {{ env }},
{{ default }}), while runtime invocation receives resolved values.
- Add generic DB assertion step `the stored <Kind> configuration for "X" should contain:`
backed by kind→table mapping in steps_template.go
- Refactor GetStoredRestAPISourceConfigurationWithRetry to delegate to new
GetStoredSourceConfigurationWithRetry(ctx, kind, table, handle)
- LlmProvider scenario: {{ secret }} in upstream auth header; verify echoed value
- LlmProxy scenario: {{ secret }} in set-headers policy; verify echoed header
- Mcp scenario: {{ env | default }} in upstream URL; verify tools/call invocation
Signed-off-by: Renuka Fernando <renukapiyumal@gmail.com>
2 participants
Purpose
Extend template-rendering integration tests beyond RestApi to cover LlmProvider, LlmProxy, and Mcp. Each scenario validates the render contract: API responses and DB storage preserve unrendered template expressions ({{ secret }}, {{ env }}, {{ default }}), while runtime invocation receives resolved values.
the stored <Kind> configuration for "X" should contain:backed by kind→table mapping in steps_template.go