fix(builder): allow Enter key to create new lines in Additional Info textareas (#763) - #788
fix(builder): allow Enter key to create new lines in Additional Info textareas (#763)#788Frankli9986 wants to merge 1 commit into
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found across 11 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="apps/frontend/components/resume/resume-two-column.tsx">
<violation number="1" location="apps/frontend/components/resume/resume-two-column.tsx:422">
P2: Section visibility checks use unfiltered array length, so whitespace-only additional fields can render empty sections with a title but no content</violation>
</file>
<file name="apps/frontend/components/resume/resume-single-column.tsx">
<violation number="1" location="apps/frontend/components/resume/resume-single-column.tsx:397">
P2: Whitespace-only additional items can still pass the raw length checks, so the section/rows render even though the joined display text is empty.</violation>
</file>
<file name="apps/backend/app/llm.py">
<violation number="1" location="apps/backend/app/llm.py:920">
P2: Removing DeepSeek's timeout multiplier regresses a supported provider by lowering its timeout budget from 1.3x to the default 1.0x, which can cause avoidable request timeouts.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
- Filter whitespace-only items in section visibility checks (two-column & single-column) - Restore deepseek 1.3x timeout multiplier in llm.py
44640df to
aebefdf
Compare
aebefdf to
b76abcf
Compare
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| detail="Confirmation required. Pass confirm=RESET_ALL_DATA in request body.", | ||
| ) | ||
| await db.reset_database() | ||
| db.reset_database() |
There was a problem hiding this comment.
CRITICAL: Missing await on async function call
db.reset_database() is defined as async def reset_database(self) (line 749 in database.py). Calling it without await creates a coroutine object that is never awaited — the database reset never executes. The endpoint returns success but no data is actually deleted. This was previously await db.reset_database().
| db.reset_database() | |
| await db.reset_database() |
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| cleaned = (request.api_base or "").strip() | ||
| stored["api_base"] = cleaned or None | ||
| if request.api_key is not None: | ||
| stored["api_key"] = request.api_key |
There was a problem hiding this comment.
WARNING: API key written to plaintext config
This writes the API key into config.json as plaintext via the stored dict. The previous version explicitly avoided writing API keys through this endpoint to prevent shadowing across providers. Now any API key sent to PUT /config/llm-api-key persists in plaintext on disk — weaker than the previous encrypted SQLite store.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| db.replace_api_keys(ciphertexts) | ||
| config = load_config_file() | ||
| config["api_keys"] = api_keys | ||
| save_config_file(config) |
There was a problem hiding this comment.
WARNING: API keys persisted in plaintext to disk
save_config_file (line 38) now writes config directly to config.json without stripping api_keys. The previous version of save_config_file explicitly called config.pop('api_keys', None) and config.pop('api_key', None) before writing. All provider API keys are now stored as plaintext JSON on disk — a regression from the encrypted SQLite key store.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| @@ -403,25 +396,25 @@ const AdditionalSection: React.FC<{ | |||
| {technicalSkills.length > 0 && ( | |||
There was a problem hiding this comment.
SUGGESTION: Visibility check inconsistent with rendering — empty section headers possible
technicalSkills.length > 0 uses raw array length, but the rendering at line 399 uses technicalSkills.filter((s) => s.trim()).join(', '). If the array contains only empty/whitespace strings (e.g. from blank Enter lines), the condition is true but the rendered content is empty — causing an orphaned section label "Technical Skills:" with no value.
The same issue applies to languages, certificationsTraining, and awards in this component, and to the hasContent check at lines 384-388 which also uses raw .length > 0 instead of filtered length.
Consider filtering before the length check:
{technicalSkills.filter((s) => s.trim()).length > 0 && (
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
|
||
| {/* Awards Section */} | ||
| {isSectionVisible('additional') && awards.length > 0 && ( | ||
| {isSectionVisible('additional') && additional?.awards && additional.awards.length > 0 && ( |
There was a problem hiding this comment.
SUGGESTION: Awards visibility check inconsistent with rendering
additional.awards.length > 0 uses raw length, but the rendering at line 406 applies .filter((s) => s.trim()). If awards contains only empty strings, the section header "Awards" renders with an empty list. The certificationsTraining, technicalSkills, and languages checks in this same component use .filter((s) => s.trim()).length > 0 for consistency — awards should match.
| {isSectionVisible('additional') && additional?.awards && additional.awards.length > 0 && ( | |
| {isSectionVisible('additional') && additional?.awards && additional.awards.filter((s) => s.trim()).length > 0 && ( |
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 5 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)CRITICAL
WARNING
SUGGESTION
Other Observations (not in diff)Issues found in unchanged code that cannot receive inline comments:
Files Reviewed (10 files)
Fix these issues in Kilo Cloud Reviewed by qwen3.7-plus-20260602 · 633,075 tokens |
1 participant
Closing: the underlying textarea/Enter-key fix was already merged via upstream main (see #763). The remaining branch changes were unrelated and have been cleaned up separately.