r2r k8s manifests with kustomize

[qdrddr]

/deployment/k8s folder containing manifests to deploy with the kustomize tool @NolanTrem.

Inflate like this kustomize build deployment/k8s/kustomizations --enable-helm > deployment/k8s/kustomizations/r2r.kustimized.yaml then deploy as usual with kubectl apply -f or using a GitOps tool such as ArgoCD.

---

Important

Add Kubernetes manifests and configurations for deploying with Kustomize, including Helm charts, patches, and secrets management.

• Kubernetes Manifests:
  • Add kustomizations for deploying with Kustomize in deployment/k8s.
  • Include ConfigMaps for hatchet, r2r, unstructured, and initialization scripts.
  • Add Deployments and Services for hatchet-dashboard, hatchet-engine, r2r, r2r-dashboard, r2r-graph-clustering, r2r-nginx, and unstructured.
  • Add StatefulSets for hatchet-rabbitmq and r2r-pgvector.
• Helm Charts:
  • Configure Helm charts for hatchet-ha and postgresql with specific values files.
• Patches:
  • Add patches to remove Helm-generated secrets and modify service configurations.
• Secrets Management:
  • Add externalsecret_hatchet.yaml and externalsecret_r2r.yaml for managing secrets with External Secrets.
  • Include example secrets in secrets_hatchet.yaml and secrets_r2r.yaml.

^{This description was created by for f45a099. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to f45a099 in 3 minutes and 22 seconds. Click for details.

• Reviewed 2716 lines of code in 31 files
• Skipped 0 files when reviewing.
• Skipped posting 34 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. deployment/k8s/kustomizations/cm-hatchet_OLD.yaml:10

• Draft comment:
  Remove or archive this OLD configmap file to avoid confusion with the current one.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:83

• Draft comment:
  Typo: 'thsi' should be corrected to 'this' in the comment.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the typo exists, it's in a comment rather than in code. Comments are documentation and typos in them don't affect functionality. The rules state we should only keep comments that require code changes. Additionally, there's another typo in the same comment ('Bunding' instead of 'Binding') that wasn't even caught, suggesting this kind of nitpicking isn't particularly thorough or valuable. The typo could make the documentation slightly less professional and harder to read. Some teams might value maintaining high quality even in comments. While documentation quality is important, this type of minor typo doesn't significantly impact readability or understanding. The rules explicitly state to only comment when code changes are required. Delete this comment as it only points out a documentation typo and doesn't require any functional code changes.

3. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:83

• Draft comment:
  Typo in 'Bunding' – consider changing to 'Binding'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the typos, comments about typos in documentation/comments are generally low value unless they significantly impact understanding. In this case, both typos are obvious and don't impair understanding - "thsi" is clearly "this" and "Bunding" is clearly "Binding". The comment doesn't affect functionality. The typos could be seen as unprofessional and fixing them would improve code quality. Multiple typos in one line might indicate a lack of attention to detail. While fixing typos is good, PR comments should focus on substantive issues. These typos are in a comment line, not code, and don't impact functionality or understanding. The comment should be removed as it points out minor typos in a comment that don't impact functionality or comprehension.

4. deployment/k8s/manifests/examples/ingress-r2r.yaml:3

• Draft comment:
  Spelling issue: correct 'enyone can acess' to 'anyone can access' in the comment.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While spelling mistakes exist, they are in a comment that doesn't affect functionality. The rules state we should only keep comments that require clear code changes. Spelling in comments, while nice to fix, is not critical enough to warrant a PR comment. This feels more like a nitpick that could be handled in person or ignored. The spelling mistakes could make the documentation less professional and harder to understand for non-native English speakers. Documentation quality is important. While documentation quality matters, this is an example manifest file and the meaning is still clear despite the typos. This doesn't meet the bar of "clearly requiring a code change". Delete this comment as it's about documentation formatting rather than required code changes, and doesn't meet the high bar set in the rules for keeping comments.

5. deployment/k8s/kustomizations/patches/hatchet-rabbitmq-sts.yaml:32

• Draft comment:
  Ensure environment variables used in liveness/readiness commands (RABBITMQ_USERNAME and RABBITMQ_PASSWORD) are set properly; an empty default value might mask configuration issues.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the author to ensure that environment variables are set properly, which is similar to asking them to double-check or verify something. This violates the rule against asking the author to ensure behavior is intended or to double-check things.

6. deployment/k8s/kustomizations/kustomization.yaml:65

• Draft comment:
  Consider removing commented-out resource references (e.g., pgvector-sts, pgadmin, hatchet-init-job) if they are not used to simplify maintenance.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a new file, so these comments were intentionally added this way. The commented sections might serve as documentation or future reference. Since this is infrastructure code, having commented options could be valuable for different deployment scenarios. The comment is about code cleanliness, but it's not addressing a clear problem or bug. The commented code might be intentionally kept as documentation or for different deployment configurations. The author might have a specific reason for keeping these options visible. While the comment suggests a valid code cleanup, it's not addressing a critical issue and the commented sections might serve a documentation purpose in infrastructure code. The comment should be removed as it's making a style suggestion about intentionally commented code in a new file, which might serve a valid documentation purpose.

7. deployment/k8s/manifests/examples/secrets_hatchet.yaml:3

• Draft comment:
  Ensure that secrets with placeholder values (+++++++) are securely managed and not committed in production.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure that secrets are securely managed and not committed in production. It is not making a specific code suggestion or pointing out a specific issue in the code. It is more of a general reminder or best practice, which violates the rule against asking the author to ensure something is done.

8. deployment/k8s/manifests/examples/secrets_r2r.yaml:3

• Draft comment:
  Double-check that secrets are encrypted/transmitted securely and that keys align with expected configuration.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to double-check something, which violates the rule against asking for confirmation or verification. It doesn't provide a specific suggestion or point out a specific issue in the code.

9. deployment/k8s/kustomizations/helm-values_hatchet.yaml:9

• Draft comment:
  Consider standardizing boolean values across the configuration. For example, 'serverAuthCookieInsecure' is set to "t" while later 'grpcInsecure' is "true". Using explicit booleans (true/false) will improve clarity and consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a new file being added, so all code is technically "changed". The inconsistency is real and visible. However, there may be a reason for using "t" vs "true" - it could be a requirement of the underlying system. Without knowing the codebase better, changing this could break functionality. The comment assumes these values are interchangeable without evidence. We don't know if "t" vs "true" is actually interchangeable in this system. The different formats might be intentional based on how different services parse these values. While consistency would be nice, making this change without understanding the underlying requirements could cause issues. The current format may be necessary. We should not keep this comment since we don't have strong evidence that the suggested change is safe to make. The different boolean formats may be intentional.

10. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:83

• Draft comment:
  Typo detected: 'thsi' should be 'this' and 'Bunding' should be 'Binding'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the typos are real, they are in a comment that doesn't affect functionality. The typos don't make the comment incomprehensible - it's still clear what it means. Comments about pure typos in comments are generally too minor to be worth a PR comment unless they significantly impact understanding. The typos could be seen as unprofessional and fixing them would improve code quality. Documentation is important for maintainability. While documentation quality matters, this level of nitpicking on obvious typos that don't impact understanding creates noise in PR reviews and distracts from more important issues. This comment should be deleted as it points out minor typos in a comment that don't significantly impact code understanding or maintainability.

11. deployment/k8s/kustomizations/include/r2r-initc.yaml:113

• Draft comment:
  The volume mount for the hatchet API key is commented out. If HATCHET_CLIENT_TOKEN is required from /hatchet_api_key/api_key.txt, ensure that the corresponding volume is mounted (or remove the comment) to avoid runtime issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The code has a proper fallback mechanism. The primary source is the environment variable which is properly configured. The file path is only a secondary fallback. Since the env var source is marked as optional, this suggests the entire hatchet functionality is optional. The commented out sections appear intentional rather than accidental. I could be wrong about the optionality - maybe hatchet is required but the optional flag is misconfigured. Also, there might be other parts of the system that expect this file to exist. The consistent commenting out of all hatchet-related volume mounts and checks (lines 29-30, 54-56, 114-117, 134-140) suggests this was an intentional change rather than an oversight. The comment should be deleted as the code appears to handle the hatchet token appropriately through environment variables, with the file path being an intentionally removed fallback mechanism.

12. deployment/k8s/manifests/examples/externalsecret_hatchet.yaml:23

• Draft comment:
  Verify that the templated secret keys (e.g. '{{ .RABBITMQ_ADMIN_EMAIL }}') match the keys available in your secret store. Mismatches may prevent proper secret injection.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify that the templated secret keys match the keys in the secret store. This falls under asking the author to double-check things, which is against the rules.

13. deployment/k8s/kustomizations/include/cm-hatchet_OLD.yaml:9

• Draft comment:
  The legacy configuration file appears to be superseded by 'cm-hatchet.yaml'. Consider removing or archiving 'cm-hatchet_OLD.yaml' to reduce maintenance overhead.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The filename ending in "_OLD" strongly suggests this is a legacy file. However, we don't have direct evidence of the other file cm-hatchet.yaml that would supersede it. According to our rules, we should not make assumptions about files we can't see. The comment requires knowledge about another file's existence and contents to be valid. We might be missing important context - perhaps this OLD file is being intentionally added for comparison or backup purposes. Also, we don't have proof that cm-hatchet.yaml exists or contains the same configuration. While the _OLD suffix is suggestive, we need concrete evidence about the relationship between files to make this recommendation. Without seeing cm-hatchet.yaml, we can't be certain this comment is correct. We should delete this comment since it requires knowledge about other files that we don't have access to in order to verify its correctness.

14. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:111

• Draft comment:
  Consider removing or reducing verbose debug output (e.g. use of 'ls -la') in production scripts to avoid exposing sensitive file metadata.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

15. deployment/k8s/kustomizations/helm-values_hatchet.yaml:9

• Draft comment:
  In the 'sharedConfig' section, the keys 'serverAuthCookieInsecure', 'serverAuthSetEmailVerified', and 'serverAuthBasicAuthEnabled' use the shorthand 't' to represent a true value, whereas later the key 'grpcInsecure' uses 'true'. For consistency and clarity in YAML boolean representations, please consider using a consistent value (preferably 'true' or a proper boolean literal) across the file.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The rules state we should not make purely informative comments. While this is a valid style observation, it's more of a preference than a critical issue. The values will work either way - YAML accepts various boolean representations. This seems like a minor consistency issue that doesn't affect functionality. The inconsistency could potentially lead to confusion for future maintainers. Different boolean representations might make the config harder to read. While consistency is good, this is a new file and both formats are valid YAML. The comment doesn't point out a functional issue that needs fixing. This comment should be removed as it's purely about style consistency and doesn't highlight a functional issue that requires changing.

16. deployment/k8s/kustomizations/helm-values_hatchet.yaml:218

• Draft comment:
  The file does not end with a newline. It is generally good practice to have a trailing newline at the end of files to avoid potential issues with some tools.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While having a trailing newline is indeed a common convention, this is a very minor issue. The file will still work perfectly fine without it. Some tools might complain, but it's not a functional issue. Our rules specifically say not to make comments that are obvious or unimportant. The missing newline could potentially cause issues with some tools or make diffs less clean. It's a widely accepted convention in software development. While it's a valid convention, this kind of minor formatting issue doesn't meet our bar for "clearly a code change required" - it's more of a nice-to-have. The comment should be removed as it doesn't meet our threshold for importance and actionability. It's too minor of an issue given our strict commenting guidelines.

17. deployment/k8s/kustomizations/helm-values_postgresql.yaml:8

• Draft comment:
  Consider adding a space after '#' in the comment to improve readability. For example, change "#creates hatchet database" to "# creates hatchet database".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the suggestion would improve readability slightly, this is an extremely minor style issue. The comment is still perfectly readable and functional without the space. This feels like unnecessary nitpicking that doesn't materially improve code quality. The rules specifically say not to make obvious or unimportant comments. The suggestion does follow standard YAML style guides, and consistent formatting can make code more maintainable in the long run. However, this is such a minor formatting issue that it doesn't warrant a PR comment. The benefit is too small to justify the overhead of a review comment. Delete this comment as it's too minor of a style issue to be worth addressing in code review.

18. deployment/k8s/kustomizations/include/cm-hatchet.yaml:20

• Draft comment:
  Trivial: Consider adding a newline at the end of the file to adhere to common style guidelines.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While missing newlines at end of files can cause issues in some contexts, this is a very minor style issue. Most modern tools handle this automatically. The comment is marked as "Trivial" which acknowledges this. Given our rules about not making purely stylistic or obvious comments, this seems like unnecessary noise in the PR review. Missing newlines can cause issues when concatenating files or in certain Git operations. Some tools expect files to end with newlines. While true, this is still a minor style issue that would likely be caught by linters or formatters if it was important for this codebase. The rules explicitly say not to make obvious or unimportant comments. Delete this comment as it's a trivial style suggestion that doesn't warrant interrupting the PR review process.

19. deployment/k8s/kustomizations/include/cm-hatchet_OLD.yaml:40

• Draft comment:
  The file is missing a newline at the end. Please add a trailing newline to follow standard file formatting conventions.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While adding trailing newlines is a common convention, this seems like a very minor formatting issue. Many IDEs and git tools handle this automatically. The file is also named with "_OLD" suggesting it might be temporary or for reference. The comment doesn't affect functionality and is quite trivial. Missing trailing newlines can cause issues with some tools and make diffs less clean. It's a widely accepted best practice in file formatting. While true, this is an extremely minor issue that would likely be caught by linters or formatters. It doesn't impact functionality and isn't worth a PR comment. This comment should be removed as it's too trivial and doesn't meet the bar of being an important enough issue to raise in a PR review.

20. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:83

• Draft comment:
  Typo noticed on line 83: Consider changing "thsi" to "this" and "Bunding" to "Binding" for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the typos are real, they are in a comment that doesn't affect functionality. The typos are minor and don't significantly impact readability or understanding. Comments about purely cosmetic issues like typos in comments are generally not worth keeping unless they seriously impact understanding. The typos could indicate a lack of attention to detail, and fixing them would improve code quality. Comments are documentation and should be professional. While professional documentation is important, this is a minor cosmetic issue in an internal comment that doesn't significantly impact understanding. The meaning is still clear despite the typos. Delete the comment as it addresses a minor cosmetic issue that doesn't impact functionality or significantly affect readability.

21. deployment/k8s/kustomizations/include/cm-init-scripts-hatchet.yaml:149

• Draft comment:
  Typographical error on line 149: "withing" should be corrected to "within".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While this is technically correct - there is a typo - it's an extremely minor issue in a comment that doesn't affect functionality. The meaning is still clear despite the typo. Comments about typos in comments are generally too trivial to be worth raising in a PR review unless they significantly impact understanding. The typo could theoretically cause confusion for non-native English speakers. Also, maintaining high quality even in comments shows attention to detail. While quality is important, this particular typo is extremely minor and the meaning remains clear. PR comments should focus on more substantive issues. This comment should be deleted as it addresses too minor of an issue to be worth raising in a PR review.

22. deployment/k8s/kustomizations/include/hatchet-dashboard-initc.yaml:1

• Draft comment:
  It looks like there might be a typographical error in the file name 'hatchet-dashboard-initc.yaml'. Please check if 'initc' is intended or if it should be corrected to something like 'hatchet-dashboard-init.yaml' for naming consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% File naming is generally an implementation detail unless it breaks something. The file appears to be functional Kubernetes YAML. The 'initc' in the name might be intentional since it contains (commented) init container config. Without more context about naming conventions or seeing other files, we can't be certain this is actually wrong. The filename could be confusing to future maintainers. Maybe there's a standard naming convention in the project we're unaware of. Even if there is a naming convention, this is a relatively minor issue that doesn't affect functionality. We don't have strong evidence that this is actually wrong. The comment should be deleted as it's speculative, doesn't affect functionality, and we don't have strong evidence that the filename is actually incorrect.

23. deployment/k8s/kustomizations/include/hatchet-engine-initc.yaml:1

• Draft comment:
  The file name 'hatchet-engine-initc.yaml' seems to include an unexpected 'c'. If this is a typo, consider renaming it to 'hatchet-engine-init.yaml' for clarity and consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% According to the rules, we should not comment on file names or renames. The 'c' in the filename could be intentional (possibly standing for 'container' or 'config'). Without more context about the naming convention in the project, we can't be sure this is even a problem. The functionality of the code is not affected by the filename. The filename might actually follow a specific naming convention in the project that we're not aware of. The 'c' could be meaningful. Even if the 'c' is meaningful or not, commenting on filenames is explicitly against our review rules unless it causes functional issues, which this doesn't. The comment should be deleted as it violates the rule about not commenting on file names and renames, and it doesn't affect the functionality of the code.

24. deployment/k8s/kustomizations/include/hatchet-engine-initc.yaml:37

• Draft comment:
  The comment on line 37 reads: "# Wait for config files to be generated by hatchet-init-job and pushed into Secret and be not empty." Consider rephrasing it to improve clarity, for example: "# Wait for config files generated by hatchet-init-job to be pushed into a Secret and ensure they are not empty."
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new file being added, so it is about changes. However, the comment is purely stylistic and doesn't improve code quality or fix any issues. The existing comment is already clear and functional. Making purely stylistic suggestions about comment wording violates the rule about not making purely informative comments. Perhaps clearer documentation could help future maintainers better understand the initialization process. The suggested wording is arguably more grammatically correct. While better documentation is valuable, this minor rewording doesn't materially improve understanding and creates unnecessary noise in the PR review process. Delete this comment as it only suggests a minor stylistic change to documentation without improving code quality or fixing any issues.

25. deployment/k8s/kustomizations/include/hatchet-init-job.yaml:91

• Draft comment:
  Typo in comment: 'in case the secrets do not exists, create the directories'. Consider changing 'exists' to 'exist' for correct grammar.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the grammar correction is technically correct, comments about typos in comments are generally not valuable enough to warrant a PR comment. The meaning is clear despite the grammatical error. This is especially true for shell script comments which are primarily for developer reference. The comment doesn't affect functionality or code quality. The typo could indicate a lack of attention to detail, and fixing it would improve code quality marginally. Professional code should be well-written, including comments. The benefit of fixing this minor grammatical error is outweighed by the cognitive overhead of processing the PR comment. The original meaning is perfectly clear. Delete the comment as it provides minimal value and doesn't affect code functionality or maintainability.

26. deployment/k8s/kustomizations/include/r2r-initc.yaml:1

• Draft comment:
  It appears that the file name 'r2r-initc.yaml' may contain a typographical error with the 'initc' part. Please double-check whether this was intentional or if it should be renamed (for example, to 'r2r-init.yaml' or similar) to avoid confusion.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The "initc" suffix likely stands for "init containers" which is exactly what this file contains. This appears to be an intentional naming choice to indicate the file's purpose. The comment is asking for confirmation about naming, which violates our rules about not asking for confirmations or intentions. The filename could be confusing to newcomers, and having a more standard naming convention might improve code maintainability. While clarity in naming is important, the current name is descriptive of the file's contents, and asking for confirmation about naming choices violates our review rules. This is a matter of preference rather than a technical issue. Delete the comment as it violates the rule about not asking for confirmations or explanations of intent, and the filename appears to be an intentional choice that describes the file's contents.

27. deployment/k8s/kustomizations/include/r2r-initc.yaml:153

• Draft comment:
  The file is missing a trailing newline at the end. While this is a minor stylistic issue, adding a newline can improve consistency and compatibility with some tools.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. While missing trailing newlines can cause issues with some tools, this is a very minor issue that would likely be caught by linters or formatters if it was important to the team. The comment doesn't suggest any critical changes that would affect functionality. The missing newline could potentially cause issues with some Git tools or text processing utilities. Some teams consider this a required standard. While true, if this was an important standard for the team, it would be enforced by their CI/CD pipeline or linters. This kind of minor stylistic feedback creates noise without adding significant value. The comment should be removed as it's a minor stylistic issue that doesn't require immediate attention and would be better handled by automated tools if important to the team.

28. deployment/k8s/kustomizations/kustomization.yaml:1

• Draft comment:
  Typographical note: The comment on line 1 refers to an output file 'r2r.kustimized.yaml'. This seems to be a typo; consider renaming it to 'r2r.kustomized.yaml' for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the typo is real, this is just a comment in the code showing an example command. The typo doesn't affect functionality. The comment is purely about spelling/documentation and doesn't suggest any meaningful code changes. According to the rules, we should not make purely informative comments or comments about obvious/unimportant issues. The typo could potentially cause confusion if someone tries to copy-paste and run this command. It might be worth fixing for documentation accuracy. Even if someone copy-pastes this command, they would likely notice and fix the typo themselves. This is too minor an issue to warrant a PR comment. This comment should be deleted as it's purely about documentation and doesn't suggest any meaningful code changes.

29. deployment/k8s/manifests/examples/externalsecret_r2r.yaml:161

• Draft comment:
  Typo detected: 'Ebable' should be corrected to 'Enable' in the response format comment.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While this is technically correct (there is a typo), it's a very minor issue in a comment. The comment is still perfectly understandable despite the typo. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. This feels like unnecessary noise in the PR review. The typo could theoretically cause confusion for future developers reading the config file. Documentation quality is important. The typo is so minor and the meaning is so clear that it's extremely unlikely to cause any real confusion. The cost of the noise in the PR review outweighs the tiny benefit of fixing this. This comment should be deleted as it points out a trivial typo that doesn't impact functionality and creates unnecessary noise in the PR review.

30. deployment/k8s/manifests/examples/externalsecret_r2r.yaml:196

• Draft comment:
  Typo detected: 'relationshipt extraction' likely should be 'relationship extraction'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct - there is a typo - it's an extremely minor issue in a comment that doesn't affect functionality. The comment is about a change in the diff since this is a new file, but fixing typos in comments is not important enough to warrant a PR comment. The typo could potentially cause confusion for future developers reading the config file. Documentation quality matters. While documentation quality matters, this particular typo is extremely minor and obvious - no developer would be confused by "relationshipt" vs "relationship" in a comment. The cognitive overhead of reviewing this comment outweighs its value. Delete this comment as it points out an extremely minor typo in a comment that doesn't impact functionality or clarity.

31. deployment/k8s/manifests/examples/externalsecret_r2r.yaml:316

• Draft comment:
  Typo detected: 'preceeding' should be corrected to 'preceding' in the comment describing chunk enrichment settings.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically a spelling error, it's in a comment that explains a configuration parameter. The misspelling doesn't affect functionality, and fixing it would be a purely cosmetic change. Our rules state we should not make purely informative comments or comments about obvious/unimportant issues. The spelling error could potentially cause confusion for future readers of the documentation. Documentation quality is important for maintainability. While documentation quality matters, this minor spelling error in a config comment doesn't meaningfully impact understanding - the meaning is still clear from context. This kind of nitpick creates noise in the review process. Delete this comment as it's too minor and doesn't affect functionality or meaningful documentation quality.

32. deployment/k8s/manifests/examples/ingress-r2r.yaml:1

• Draft comment:
  Typographical error: 'Dependancy' on line 1 should be 'Dependency'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, it's a very minor spelling issue in comments that doesn't affect functionality. The rules state not to make purely informative comments or comments that are obvious/unimportant. Spelling in comments is not a critical issue that requires a code change. The misspelling appears multiple times, suggesting it might be a systematic issue worth fixing for consistency and professionalism. While consistent spelling is nice, this is still just a cosmetic issue in comments that doesn't impact functionality or code quality in any meaningful way. Delete this comment as it violates the rule about not making purely informative comments that don't require clear code changes.

33. deployment/k8s/manifests/examples/ingress-r2r.yaml:9

• Draft comment:
  Typographical error on line 9: 'Dependancy' should be corrected to 'Dependency'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct, this is a very minor spelling error in a comment. It doesn't affect functionality at all. The rules specifically say not to make purely informative comments and to avoid obvious or unimportant issues. This seems like a trivial issue that doesn't require a formal PR comment. The misspelling could propagate if copied elsewhere in the codebase. Multiple instances suggest it might be a systematic error worth fixing. While consistent spelling is good, this is still just a comment typo with no functional impact. A PR comment is too formal for this - it could be mentioned in passing or fixed directly. This comment should be deleted as it violates the rules about not making purely informative comments and avoiding unimportant issues.

34. deployment/k8s/manifests/examples/ingress-r2r.yaml:16

• Draft comment:
  Typographical error on line 16: 'Dependancy' should be 'Dependency'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the spelling error exists and the correction is accurate, this is a very minor issue in a comment. Comments are documentation, not code, and this typo doesn't affect functionality. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. This seems to fall into that category. The typo appears multiple times in the file, suggesting it might be a systematic issue worth fixing for consistency and professionalism. While consistency is good, fixing comment typos is still a very minor issue that doesn't affect functionality or maintainability in any meaningful way. Delete the comment as it violates the rule about not making purely informative comments and comments that are unimportant.

Workflow ID: wflow_cLLVkv1cnwK5DHAn

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Consider using boolean values (true/false) instead of strings ("t") for flags like serverAuthCookieInsecure for clarity and type-safety.

Suggested change

	serverAuthCookieInsecure: "t" # allows cookies to be set over http
	serverAuthCookieInsecure: true # allows cookies to be set over http

[ellipsis-dev]

Typo detected: 'graphrag_entity_deduplication' in the prompt likely should be 'graph_entity_deduplication'.

Suggested change

	graph_entity_deduplication_prompt = "graphrag_entity_deduplication"
	graph_entity_deduplication_prompt = "graph_entity_deduplication"

[ellipsis-dev]

Typographical errors on line 3: 'enyone' should be 'anyone' and 'acess' should be 'access'.

Suggested change

	# Note: without authentication, enyone can acess your app, see your data and modify your settings!
	# Note: without authentication, anyone can access your app, see your data and modify your settings!