こんばんは
UiPath Studio 2024.10 enterprise editionを使い、クラシックデザインアクティビティ
で開発しています。
UiPathにつき、最近興味深い事実が分かったので、共有させてください。
◉変数パネルで変数名を旧変数名から新変数名に変更後、プロジェクトをデバッグ実行したら、「旧変数がありません。」という検証エラーが出力パネルに表示された。ただ不思議なことに、ワークフローは何も変更していないのに、このエラーは翌日以降出なくなった。
◉外部ワークフローファイル呼び出しアクティビティに設定している引数名を変更したら、「パラメータとして設定している引数が異常です。」という意味の検証エラーが出力パネルに表示された。ただ不思議なことに、ワークフローは何も変更していないのに、このエラーは翌日以降出なくなった。
変数・引数名を変数パネルで変更した場合、どこかの環境に旧変数名が残る場合があるようです。ただ時間が経過するとその残骸は消えるようです。
似た経験をされた方がいれば教えてください。
Hello @gorby
Have you checked the execution logs to perhaps get a better understanding of what happened?
And are you able to attach them here for our (and perhaps UiPath’s) reference?
Regards
Soren
Sorry I cannot due to compliance-related reasons. But Have you ever experienced a situation where a variable name change is not reflected?
Regards,
gorby
Hmm not that I can think of…
But I have seen Studio being buggy (eg. not loading arguments on Invoke Workflow), where a restart of the project (Close and Re-open) has fixed the problem.
Perhaps this is one of those cases..
As I understand it, the error has “fixed itself” now, right?
As I wrote, this error has fixed itself now. It is really what they say “agentic self healing function” isnt it?
PC 上でプログラムを実行するには、まず 実行可能な形式へコンパイルする工程が必要になります。この工程はStudioが自動的に行っているのでユーザが意識することはほぼありません。
また、XAML は人間が読みやすいように記述されていますが、UiPath が実際に実行しているのは、XAML を元に生成された中間コード（コンパイル後の処理内容）になります。
このあたりは、普段からコードを書いている人なら自然とイメージしやすい点かもしれませんが、最近のコーディングツールは便利になっている分、仕組みが見えにくくて分かりづらいですね。
そのため、アクティビティの構造が変わっていない場合や、変数名のような軽微な変更だけのときは、Studio が即座に再コンパイルを行わず、前回のコンパイルした中間コードを参照してしまうことも考えられます。
To execute a program on a PC, it first needs to be compiled into an executable form.
XAML is written in a human-readable structure, but what UiPath actually runs is the intermediate code generated from the XAML (the compiled representation).
For those who regularly write code, this behavior may feel intuitive, but modern development tools have become so convenient that the underlying mechanisms can be harder to see and understand.
Because of this, when the activity structure itself hasn’t changed and only minor updates—such as variable name changes—are made, Studio may not immediately trigger a recompilation and could continue referring to the previously compiled intermediate code.
ワークフローが変わっても即座に再コンパイルを行わないのは仕様上のバグに見えます。
UiPath Studio がワークフローを変更してもすぐに再コンパイルを行わない（あるいは行えない）ように見えるのは、仕様によるものかと思います。
Studio はパフォーマンスを優先するため、変更内容を解析して ワークフロー構造に影響がある場合のみ再コンパイルし、軽微な変更については 既存のキャッシュを利用して高速に処理する設計になっています。
これは UiPath 特有の挙動ではなく、Eclipse や IntelliJ、Visual Studio など主要な IDE でも一般的に採用されている方法です。理由はシンプルで、ビルド時間の短縮や CPU／メモリ使用量の抑制により全体の操作性を向上させるためです。
そのため多くの開発環境では 差分コンパイル が標準であり、変数名の変更など軽微な修正は差分として認識されず、キャッシュが優先されるケースがあります。
たしかに利用者の視点からすると、「変更したのに反映されない＝バグでは？」と感じられる場面があるのは確かです。
しかし、こういった場合でもすぐにバグと判断するのではなく、前述のような仕組みから 「再コンパイルが正しく行われていないのだな」 と捉え、XAML を再読み込みしたり IDE を再起動したりするのが、エンジニア業界では一般的な対処方法かと思います。
これは パフォーマンスとのトレードオフを踏まえた業界共通のアプローチであり、一般的な IDE が持つ仕様でもあります。少しわかりにくい挙動ですが、設計上そうなっているため、慣れていないと戸惑いやすいところです。
It seems that the reason UiPath Studio does not immediately recompile a workflow after every modification is simply due to its intended design, not a defect.
Studio prioritizes performance by analyzing the nature of each change:
only modifications that affect the workflow’s structure trigger a recompilation, while minor edits are handled using cached workflow data to keep execution and debugging responsive.
This behavior is not unique to UiPath. Major IDEs such as Eclipse, IntelliJ, and Visual Studio use similar mechanisms. The goal is straightforward: reduce build time, minimize CPU and memory consumption, and improve overall usability.
As a result, many development environments rely on incremental (or differential) compilation, meaning that very small changes—such as renaming a variable—may not be recognized as requiring a rebuild, and previously cached data may be reused.
From a user’s perspective, it’s understandable that this could look like “the change didn’t take effect—so it must be a bug.” However, this is actually a common, industry-standard approach based on a performance trade-off that many IDEs implement to keep the editing experience smooth. UiPath follows the same model.
さすがUiPath、難解です。いつものことなのでもうびっくりはしませんが、、
As expected from UiPath, it’s complicated. But since it always happens, I’m no longer surprised.
今回の件は、IDE や開発環境に関する知識が必要な部分でして、UiPath 自体の難易度が上がるわけではありませんが、開発環境とは「そういうものなんだな」と軽く受け流してもらえれば大丈夫だと思います。
プロジェクトを閉じて開いても同じ効果が得られますか？
目的はリフレッシュ（各種データの再読み込み）なので、手段は記述した以外にもいろいろあるかと思います。おっしゃるとおりプロジェクトの保存、再読み込みも1つの手段かと思います。
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.