feat(orchestrator): Make Orchestrator's get_replica_version method a thin wrapper...#10857
Conversation
…the get_replica_version method of RegistryClient.
|
🟡 6 security issues detected below the blocking threshold. Reviewed everything up to 9da943a. The following issues were found:
Security Overview
Detected Code Changes
|
|
Oops. I forgot to rebase after PR 10851 went in (originally, this targetted the branch of that PR). Oops. I should not have set this to merge automatically. DOH! Oh well. I think in the end, the same result resulted. I'm surprised this was able to go in, was not blocked by conflict. I feel like that's usually what happens when you build on another PR, i.e. once the first one goes in, the second one says "CONFLICT! CONFLICT! WEE WOO WEE WOO! CONFLICT! CONFLICT!", but not this time for whatever reason 🤷 Ah, the wonders of git/GitHub. When are they going to learn that people continue working off their own work before it makes it into master??? |
…(in their SubnetRecord). (dfinity#10865) In order for that to be allowed, the following conditions must be met: 1. Primarily, StandardEngineReplicaVersionRecord exists 2. This feature must be enabled via flag. As per our standard way of doing this, this is currently DISABLED. The plan is to enable it once all subnets (or maybe, just Cloud Engines) understand how to handle a blank `replica_version_id` field. [👈 Previous PR][prev] [prev]: dfinity#10857 --------- Co-authored-by: Daniel Wong <daniel.wong@dfinity.org> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
... around the
get_replica_version(same name) method ofRegistryClient.This builds on PR 10840, where we started to become aware of
StandardEngineReplicaVersionRecord.👈 Previous PR | Next PR 👉