コンテンツにスキップ

バグ(Node-RED)関連

http inノードの受信先が変わるバグ(2024/10/30現在)

同じURLのhttp inノードが複数デプロイされると受信先が変わることがあります。
この現象は、ロボシュタイン専用のhttp inノードをご利用いただくことで、ほぼ確実に回避することができます。

ロボシュタイン専用のhttp inノードに関する情報はこちら
http inノードに関する情報はこちら

事象例

前提として、この事象は「デプロイ」の設定が「変更したフロー」もしくは「変更したノード」になっている場合のみ発生いたします。
httpノードバグ

  1. 「http inノード」がトリガーのフローを作成する(タブAとする)
    ・URLには「/test」を設定
    ・「タブA」は「debug 2」とする httpノードバグ

  2. 「タブAに」リクエストを投げる「http request」ノードを実行するフローを作成する(タブBとする) httpノードバグ

  3. このままの状態であれば「タブB」のhttp requestは正しく「タブA」のhttp inノードで受信される httpノードバグ

  4. 「タブA」のフローを別のタブに移行。この際設定には変更を加えない。この移行先のタブを「タブC」とする
    ・設定には変更を加えずにデプロイ
    ・「タブC」は「debug 118」とする httpノードバグ

  5. この状態であっても「タブB」のhttp requestは正しく「タブA」のhttp inノードで受信される httpノードバグ

  6. 「タブC」の「http inノード」のURLを「/test2」に変更し、デプロイ httpノードバグ

  7. この状態になると「タブB」のhttp requestは「タブC」のhttp inノードで受信されてしまう(「タブC」のhttp inノードのURLは変えているのにもかかわらず)
    ・「debug 118」で受け取っている httpノードバグ

対応策

・「http inノード」を新たに作成する際、ほかの「http inノード」では使われていないパスを指定していることを確認してから、デプロイする。

・もし仮に他の「http inノード」で使われているパスを設定した「http inノード」をデプロイしてしまった場合、デプロイの設定を「全て」にしてから再度デプロイする。もしくは、フローを再起動を実行する。
httpノードバグ

今後の対応

現在こちらの不具合の対策を考案しております。詳細が決まり次第再度ご案内申し上げます。
※このバグはNode-REDの仕様により発生しているため、弊社ではサポートの対象外となる場合があります。ご了承ください。

「変更をマージ」ボタンのダブルクリックによるバグ(2024/09/13現在)

フローエディタを複数人で編集をしている際、あるユーザーがフローを編集してデプロイを実行すると、それ以外のユーザーには他者がデプロイしたフローの情報を現在のフローエディタにマージをするか等を選択する以下の画像のようなポップアップが表示されます。

デプロイ

そのポップアップ内の「変更をマージ」ボタンをクリックすると別ユーザーがデプロイしたフローエディタの状態を取り込めますが、その際、「変更をマージ」ボタンをダブルクリックすると、ノードの表示が消えてワイヤー部分しか表示されなくなることがあります。

デプロイ

対応策

もしこの現象が発生した場合は、以下どちらかの対応をお願いいたします。
・ブラウザをリロード する。
・ロボシュタインの別の画面に遷移 し、再度フローエディタの画面に戻る。
これにより、元のフローの状態が表示されるようになります。
※「変更をマージ」ボタンをダブルクリックしなければこの事象が起こることはありませんので、ポップアップ内の「変更をマージ」ボタンをクリックする際は、一度だけクリックしてください。

一時的な対応

今後、このような不測の事態が発生した場合でもフローエディタの状態を元に戻せるよう、お客様側で定期的にフローエディタのフローを書き出して保存しておくことをお勧めいたします。

今後の対応

現在フローエディタのバージョン管理機能を開発しております。この機能により、誤ってフローエディタの状態を消してしまった場合でも、ロボシュタイン内でフローエディタの状態を元に戻せるようになります。今後改めて詳細についてご案内申し上げます。

※このバグはNode-REDの仕様により発生しているため、弊社ではサポートの対象外となる場合があります。ご了承ください。