fix(ui): i18n locale before render + fix: tool_use mismatch suggest /new (#46366, #46365)#46373
Open
xuwei-xy wants to merge 1 commit intoopenclaw:mainfrom
Open
fix(ui): i18n locale before render + fix: tool_use mismatch suggest /new (#46366, #46365)#46373xuwei-xy wants to merge 1 commit intoopenclaw:mainfrom
xuwei-xy wants to merge 1 commit intoopenclaw:mainfrom
Conversation
openclaw-barnacle
bot
added
app: web-ui
Contributor
Greptile SummaryThis PR bundles two bug fixes: (1) it detects Key changes:
Issues found:
Confidence Score: 3/5
Prompt To Fix All With AIThis is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/errors.ts
Line: 838-839
Comment:
**Overly broad `tool_use_id` alternative in regex**
The first branch of the regex — `tool_use_id` — matches any string that merely contains the substring `"tool_use_id"`, with no further constraints. This means error messages completely unrelated to a history-corruption mismatch (e.g. `"Invalid format for tool_use_id"`, `"tool_use_id is required"`, or `"Unsupported tool_use_id type"`) will all return `"Conversation history corruption detected. Please use /new to start a fresh session."`, which is incorrect advice and will confuse users.
The other two alternatives (`tool_result.*corresponding.*tool_use` and `unexpected.*tool.*block`) are adequately specific. The first alternative should be tightened to require additional context, for example:
```suggestion
const TOOL_USE_RESULT_MISMATCH_RE =
/tool_result.*tool_use_id.*not found|tool_result.*corresponding.*tool_use|unexpected.*tool.*block/i;
```
This matches the actual Anthropic API error strings exercised by the tests (`"tool_result block with tool_use_id … not found in the immediately preceding assistant message"`) while avoiding false positives on generic validation errors that happen to reference the field name.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: ui/src/ui/app.ts
Line: 119-133
Comment:
**Potential race condition between `i18n.ready` and `settingsLocale`**
Both `i18n.ready` (which loads the locale persisted in `localStorage` / derived from `navigator.language`) and `settingsLocale` (which loads the locale from app `settings`) are kicked off concurrently via `Promise.all`. Because `setLocale` is not re-entrant, whichever resolves *last* wins and sets `this.locale`.
If the two sources disagree — e.g. `localStorage` says `"zh-CN"` and `settings.locale` says `"fr"` — the final rendered locale will be whichever translation finishes loading later, which is non-deterministic. App settings should be the authoritative source, so `settingsLocale` ought to be applied *after* `i18n.ready` resolves to avoid being overwritten:
```
i18n.ready
.then(() => isSupportedLocale(this.settings.locale) ? i18n.setLocale(this.settings.locale) : Promise.resolve())
.then(() => { this.localeReady = true; }, () => { this.localeReady = true; });
```
This is a low-probability edge case (requires the two stores to diverge), but it would be an invisible, intermittent bug.
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: 55fa530 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+838
to
+839
| const TOOL_USE_RESULT_MISMATCH_RE = | ||
| /tool_use_id|tool_result.*corresponding.*tool_use|unexpected.*tool.*block/i; |
Contributor
There was a problem hiding this comment.
Overly broad tool_use_id alternative in regex
The first branch of the regex — tool_use_id — matches any string that merely contains the substring "tool_use_id", with no further constraints. This means error messages completely unrelated to a history-corruption mismatch (e.g. "Invalid format for tool_use_id", "tool_use_id is required", or "Unsupported tool_use_id type") will all return "Conversation history corruption detected. Please use /new to start a fresh session.", which is incorrect advice and will confuse users.
The other two alternatives (tool_result.*corresponding.*tool_use and unexpected.*tool.*block) are adequately specific. The first alternative should be tightened to require additional context, for example:
Suggested change
| const TOOL_USE_RESULT_MISMATCH_RE = | |
| /tool_use_id|tool_result.*corresponding.*tool_use|unexpected.*tool.*block/i; | |
| const TOOL_USE_RESULT_MISMATCH_RE = | |
| /tool_result.*tool_use_id.*not found|tool_result.*corresponding.*tool_use|unexpected.*tool.*block/i; |
This matches the actual Anthropic API error strings exercised by the tests ("tool_result block with tool_use_id … not found in the immediately preceding assistant message") while avoiding false positives on generic validation errors that happen to reference the field name.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/errors.ts
Line: 838-839
Comment:
**Overly broad `tool_use_id` alternative in regex**
The first branch of the regex — `tool_use_id` — matches any string that merely contains the substring `"tool_use_id"`, with no further constraints. This means error messages completely unrelated to a history-corruption mismatch (e.g. `"Invalid format for tool_use_id"`, `"tool_use_id is required"`, or `"Unsupported tool_use_id type"`) will all return `"Conversation history corruption detected. Please use /new to start a fresh session."`, which is incorrect advice and will confuse users.
The other two alternatives (`tool_result.*corresponding.*tool_use` and `unexpected.*tool.*block`) are adequately specific. The first alternative should be tightened to require additional context, for example:
```suggestion
const TOOL_USE_RESULT_MISMATCH_RE =
/tool_result.*tool_use_id.*not found|tool_result.*corresponding.*tool_use|unexpected.*tool.*block/i;
```
This matches the actual Anthropic API error strings exercised by the tests (`"tool_result block with tool_use_id … not found in the immediately preceding assistant message"`) while avoiding false positives on generic validation errors that happen to reference the field name.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
119
to
133
| constructor() { | ||
| super(); | ||
| if (isSupportedLocale(this.settings.locale)) { | ||
| void i18n.setLocale(this.settings.locale); | ||
| } | ||
| const settingsLocale = isSupportedLocale(this.settings.locale) | ||
| ? i18n.setLocale(this.settings.locale) | ||
| : Promise.resolve(); | ||
| Promise.all([i18n.ready, settingsLocale]).then( | ||
| () => { | ||
| this.localeReady = true; | ||
| }, | ||
| () => { | ||
| // Locale load failed; render with the default locale. | ||
| this.localeReady = true; | ||
| }, | ||
| ); | ||
| } |
Contributor
There was a problem hiding this comment.
Potential race condition between i18n.ready and settingsLocale
Both i18n.ready (which loads the locale persisted in localStorage / derived from navigator.language) and settingsLocale (which loads the locale from app settings) are kicked off concurrently via Promise.all. Because setLocale is not re-entrant, whichever resolves last wins and sets this.locale.
If the two sources disagree — e.g. localStorage says "zh-CN" and settings.locale says "fr" — the final rendered locale will be whichever translation finishes loading later, which is non-deterministic. App settings should be the authoritative source, so settingsLocale ought to be applied after i18n.ready resolves to avoid being overwritten:
i18n.ready
.then(() => isSupportedLocale(this.settings.locale) ? i18n.setLocale(this.settings.locale) : Promise.resolve())
.then(() => { this.localeReady = true; }, () => { this.localeReady = true; });
This is a low-probability edge case (requires the two stores to diverge), but it would be an invisible, intermittent bug.
Prompt To Fix With AI
This is a comment left during a code review.
Path: ui/src/ui/app.ts
Line: 119-133
Comment:
**Potential race condition between `i18n.ready` and `settingsLocale`**
Both `i18n.ready` (which loads the locale persisted in `localStorage` / derived from `navigator.language`) and `settingsLocale` (which loads the locale from app `settings`) are kicked off concurrently via `Promise.all`. Because `setLocale` is not re-entrant, whichever resolves *last* wins and sets `this.locale`.
If the two sources disagree — e.g. `localStorage` says `"zh-CN"` and `settings.locale` says `"fr"` — the final rendered locale will be whichever translation finishes loading later, which is non-deterministic. App settings should be the authoritative source, so `settingsLocale` ought to be applied *after* `i18n.ready` resolves to avoid being overwritten:
```
i18n.ready
.then(() => isSupportedLocale(this.settings.locale) ? i18n.setLocale(this.settings.locale) : Promise.resolve())
.then(() => { this.localeReady = true; }, () => { this.localeReady = true; });
```
This is a low-probability edge case (requires the two stores to diverge), but it would be an invisible, intermittent bug.
How can I resolve this? If you propose a fix, please make it concise.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Combines fixes from upstream PRs:
Merged from openclaw/openclaw PRs.