fix: 升级 Runtime 并隐藏无效后端日期 - #568
Conversation
审查者指南(小型 PR 中折叠显示)审查者指南本 PR 将随应用构建分发的 AUTO-MAS Runtime 升级至 v0.1.3,移除设置页中始终为 unknown 的后端日期展示及复制内容,并保留后端哈希信息,同时更新用户可见变更记录。 文件级变更
提示和命令与 Sourcery 交互
自定义使用体验访问你的控制面板以:
获取帮助Original review guide in EnglishReviewer's guide (collapsed on small PRs)Reviewer's Guide本 PR 将随应用构建分发的 AUTO-MAS Runtime 升级至 v0.1.3,移除设置页中始终为 unknown 的后端日期展示及复制内容,并保留后端哈希信息,同时更新用户可见变更记录。 File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
您好——我已查看您所做的更改,整体看起来很棒!
Sourcery 评估
需要人工审核。 工作流的更改会导致新构建的软件包捆绑 Runtime v0.1.3,因此运行时缺陷可能会影响已安装的客户端,而不仅仅是简单地还原源代码。影响范围是有限的,并且可以通过发布或安装修正后的软件包来修复;隐藏无效日期只是一项可逆的显示更改。
Original comment in English
Hey - I've reviewed your changes and they look great!
Sourcery assessment
Needs a human reviewer. The workflow change causes newly built packages to bundle Runtime v0.1.3, so a runtime defect could affect installed clients beyond a simple source revert. The impact is bounded and can be repaired by publishing or installing a corrected package; hiding the invalid date is only a reversible display change.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fdb8be0bbd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {{ backendUpdateInfo?.current_time || t('common.unknown') }} | ||
| </a-tag> | ||
| </div> | ||
| <div class="info-item"> |
There was a problem hiding this comment.
Preserve dates in modes that still provide them
When a user selects the supported legacy (off) or development runtime mode, Config.get_git_version() skips only the managed AUTO_MAS_EXPECTED_COMMIT shortcut and returns the repository's real commit timestamp (app/core/config.py:720-757). Removing this field and its copied value unconditionally therefore hides valid diagnostic information in those modes; suppress it only when current_time is actually unknown.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b6bd250d5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "后端更新自动在后台下载,准备好后提示下次启动生效,无需中断当前任务", | ||
| "Runtime 更新至 v0.1.3,并暂时隐藏设置页中无效的后端日期信息", |
There was a problem hiding this comment.
Collapse the two changelog entries into one
This commit adds two separate records for one PR, but the repository requires each PR to contribute exactly one concise changelog sentence. Merge the Runtime upgrade/date change and background-update behavior into a single user-facing entry.
AGENTS.md reference: AGENTS.md:L31-L33
Useful? React with 👍 / 👎.
| if (progress.progress !== undefined) { | ||
| state.progress = Math.min(100, Math.max(0, Math.round(progress.progress))) | ||
| } |
There was a problem hiding this comment.
Preserve progress across zero-valued substage events
In the supported legacy off flow, installers deliberately emit progress: 0 when moving between substages after reporting nonzero progress—for example, Python emits 50% after its check and then 0% when download begins, while repository setup emits 100% and then 0% before pulling. Unconditionally assigning that zero here makes the new progress display jump backward (and can briefly change a completed step back to processing); retain the prior nonzero value for such transition events unless this is the start of the step.
Useful? React with 👍 / 👎.
| 使用 PowerShell 7。后台更新需要桌面和 Runtime 同时使用新代码;当前工作流固定的旧 Runtime | ||
| 版本尚未包含该能力,发布前须先发布新 Runtime,再更新 `.github/workflows/build-app.yml` | ||
| 的 `RUNTIME_VERSION`。CI 会拒绝缺少后台更新协议的二进制,防止生成无法正常启动的安装包。 |
There was a problem hiding this comment.
Update the packaging guide to match the upgraded Runtime
The newly added guide says the workflow is still pinned to an old Runtime without background-update support and instructs maintainers to release and bump it, but this same commit already sets RUNTIME_VERSION to v0.1.3 and adds a protocol probe that rejects unsupported binaries. Leaving this paragraph unchanged gives packagers obsolete release instructions; describe v0.1.3 as the current validated version instead.
Useful? React with 👍 / 👎.
| content: t( | ||
| runtimeBackendUpdateAvailable.value | ||
| ? 'comp.backendUpdateReadyConfirm' | ||
| : 'comp.backendAboutUpdateWhich' |
There was a problem hiding this comment.
Warn that applying the staged update interrupts running tasks
When a staged update is ready while a scheduler task is running, this branch invokes appRestart(), whose coordinated shutdown stops the supervised backend and therefore interrupts the task. The new confirmation text only says the update will be applied and omits the explicit interruption warning used by backendAboutUpdateWhich; it also bypasses the hasRunningTasks() warning used by normal close. Preserve that warning or guard this restart so users do not terminate active automation without being told.
Useful? React with 👍 / 👎.
| version, | ||
| '--if-needed', | ||
| ]) | ||
| if (!prepared.success) return this.buildRuntimeStartFailure(prepared, [], []) |
There was a problem hiding this comment.
Preserve Runtime logs from startup preparation failures
When the new managed-mode bootstrap --if-needed fails—for example during dependency synchronization—its diagnostic output is carried in RuntimeRunResult.recentLogs/log events, not necessarily in the Runtime process's raw stderr. Passing empty log arrays to buildRuntimeStartFailure discards those events, so the initialization failure panel often has no log content; the existing initialization Runtime path explicitly captures onLog for this reason. Collect the preparation command's log events or format the logs already present on the result.
Useful? React with 👍 / 👎.
| const prepared = await this.runRuntimePreparation(client, [ | ||
| 'bootstrap', | ||
| '--version', | ||
| version, | ||
| '--if-needed', | ||
| ]) | ||
| if (!prepared.success) return this.buildRuntimeStartFailure(prepared, [], []) |
There was a problem hiding this comment.
Expose Runtime recovery actions for startup preparation failures
When the newly added startup bootstrap --if-needed returns a structured failure such as DEPENDENCY_SYNC_FAILED with rebuild-environment or open-log remediation, buildRuntimeStartFailure preserves those fields, but RuntimeBackendStartPanel consumes only success, error, and logs and offers the same generic retry/docs actions. In this scenario retrying repeats the same dependency sync and users cannot invoke the Runtime-provided rebuild or log action from the failure screen; route preparation failures through the existing Runtime failure-action handling or add equivalent actions to the backend panel.
Useful? React with 👍 / 👎.
| if (this.runtimeStopping || this.startFlight) return Promise.resolve({ updateAvailable: false }) | ||
| if (this.runtimeUpdateReady) return Promise.resolve(this.runtimeUpdateReady) | ||
| if (this.runtimeUpdateFlight) return this.runtimeUpdateFlight |
There was a problem hiding this comment.
Keep the staged-update hint until preparation is consumed
If a staged update is cached and a backend start is in progress, this early return runs before the runtimeUpdateReady check and reports a clean updateAvailable: false. The renderer treats any non-error response without staged: true as authoritative and clears its ready hint; if that startup then fails before consuming the staged update, users lose the restart prompt until the next 10-minute poll even though the prepared update still exists. Return the cached ready result first, or make the busy response non-authoritative.
Useful? React with 👍 / 👎.
|
按要求改为从 origin/dev 线性重建 PR,完整包含本地 dev 的热更新提交;请改看新 PR。 |
变更
v0.1.3unknown的后端日期,并保留后端哈希信息res/version.json记录本次用户可见变更验证
yarn lint --max-warnings 1yarn typecheckyarn test(376 passed)yarn builduv run --with pytest pytest tests --collect-only -q(459 collected)git diff --checkSourcery 总结
升级随应用分发的 Runtime,并移除设置页中无效的后端日期信息。
Bug 修复:
unknown的后端日期,同时继续保留后端哈希信息。功能增强:
文档:
res/version.json中记录本次用户可见变更。Original summary in English
Summary by Sourcery
升级随应用分发的 Runtime,并移除设置页中无效的后端日期信息。
Bug Fixes:
unknown的后端日期,同时继续保留后端哈希信息。Enhancements:
Documentation:
res/version.json中记录本次用户可见变更。