Repository navigation
feat(infra): rebuild the indexer with the API's HTTPS port open - #1455
Conversation
Time Submission Status
Submit or update total time with: Add time on top of previous submission with: See available commands to help comply with our Guidelines. |
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Add and verify HTTPS ingress deployments/infra/lib/kwil-indexer/kwil_indexer_instance.go, deployments/infra/lib/kwil-indexer/kwil_indexer_instance_test.go |
The indexer security group allows inbound TCP 443 from any IPv4 address. The test checks the synthesized rule and its description. |
Priority:
Estimated code review effort: 2 (Simple) | ~8 minutes
Change: Bug fix · Severity of issue fixed: Medium
Merge Risk: 
b6a63
-
The requested HTTPS ingress rule and its regression test are present. No actionable merge-blocking issue is established; retain the documented first-deployment rollback precaution.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly identifies the main change: opening the indexer API HTTPS port. The title is related to the security group update and is concise. Linked Issues check The change implements [ #1454].NewIndexerInstanceadds an IPv4 TCP 443 ingress rule to the indexer security group. The new construct test asserts port 443,0.0.0.0/0, and the HTTPS description in …Out of Scope Changes check The changed files stay within [ #1454]. The production change adds the required indexer security-group rule. The test verifies the synthesized rule. No unrelated behavior is changed.Full details: Linked Issues check
-
Explanation
The change implements [
#1454].NewIndexerInstanceadds an IPv4 TCP 443 ingress rule to the indexer security group. The new construct test asserts port 443,0.0.0.0/0, and the HTTPS description in the synthesized template. The PR description also reports a CloudFormation update test in which an existing manual rule remained after deployment.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 2 files.
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 2
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🛠️ Fix failing CI checks: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 help to get the list of available commands.
|
@holdex pr submit-time 1h |
Related:
The indexer's security group now allows HTTPS (TCP 443) in the infra code, so a new stack, or a replaced group, keeps the port that api.trufscan.io needs.
Caddy on the indexer instance serves the v1 API at api.trufscan.io over TLS itself, rather than through the fronting, so the API sees each visitor's address for its per-address limits. I set that Caddy site up on the host and opened 443 on the live group by hand. The prod stack's template has only the ssh rule and the fronting's HTTP rule for that group. The Caddyfile shipped in
deployments/indexerserves port 80 only, so on a stack built from this code nothing answers on 443.What changes
NewIndexerInstanceadds a TCP 443 ingress from anywhere to the indexer's security group, next to the ssh rule. Every stack that builds an indexer gets it.Deploying it
The live group already has this rule. I checked the behaviour on a throwaway CloudFormation stack: adding to the template an inline rule that already existed by hand finished
UPDATE_COMPLETEwith no duplicate error, and a hand-added rule that was not in the template stayed in place after the update.If the deploy that first carries this rule fails and rolls back, the group goes back to the old template's rules, and the revoke can take the live 443 rule with it, because EC2 matches a revoke on protocol, port and range, not on the description. After a rolled-back deploy, check that the group still allows 443 and add it back if it does not.
Tests
go test ./lib/kwil-indexer/passes, run in workspace mode as the deploy workflows set it up (go work init,go work use .andgo work use deployments/infraat the repo root). Changing the rule's port to 8443 makes the new test fail.go run cdk_main.go, ascdk.jsonruns it) builds. The existingkwil_clusterandvalidator_setconstruct tests already fail on main with a panic invalidator_set.go, so I tested the indexer construct on its own.Summary by CodeRabbit