Technical Question: Recommended approach for Action idempotency / duplicate handling
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- ドキュメント
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- java
調査の方向性
Start by reviewing the current mo-services-java Action API and the CCSDS M&C ActionExecutionRequest.requestId concept referenced in the issue. A useful outcome would document the intended retransmission and duplicate-detection mechanism for unreliable communication, including whether the API provides an identifier or whether application-level handling is expected.
索引モデルが issue の本文から書いたものです。
説明
We are currently evaluating NMF 5 for a new nanosatellite mission. Our original architecture was based on NMF 4.x, where the Action submission included a consumer-provided actionInstId.
Our main concern is the handling of duplicate Action requests in the presence of unreliable communication between ground and spacecraft.
For example:
The ground sends an Action request.
The spacecraft receives and executes the Action.
The response is lost due to a communication failure.
The ground cannot determine whether the Action was executed.
The ground retransmits the request.
The spacecraft needs to distinguish this retransmission from a new request and must not execute the Action twice.
In the newer mo-services-java API used by NMF 5, we understand that the Action execution identifier is generated by the service provider rather than supplied by the consumer.
We also noticed that the newer CCSDS M&C model contains the concept of an ActionExecutionRequest.requestId, which is intended to identify the request itself.
Our question is therefore not about the change of the API, but rather:
What is the recommended way to implement idempotent Action execution with the current mo-services-java API?
In particular:
What mechanism should a Service Consumer use to identify a retransmission of the same Action request?
How should the spacecraft detect that an Action request has already been accepted/executed when the original response was lost?
Is there an identifier or mechanism in the current API intended specifically for this purpose?
If duplicate detection is expected to be implemented at the application level, what approach is recommended?
The above scenario is particularly important for us because the communication channel between ground and spacecraft cannot be assumed to provide exactly-once delivery.
We would appreciate any guidance on the intended pattern for handling this use case with the current MO API.
Thank you in advance for your guidance.
Best regards,
Tamás
- 主要言語
- Java
- スター
- 18
- フォーク
- 11
- 平均マージ
- 4分
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
esa/mo-services-java のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
esa/mo-services-java#37 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
esa/mo-services-java#1 ·
esa/mo-services-java の issue をすべて見る
似ている issue
-
enhancement good first issue
難易度 2/5 半日 初心者へのやさしさ 66/100
apache/fineract-consumer-facing#175 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] 订单：会员凭订单号即可取消其他会员的待付款订单（取消接口不校验订单归属）対応中かも @dadiyang が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
macrozheng/mall#1016 ·
-
[Bug] The producer summary counts an unreported client version as a second version and warns about a version mix対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
apache/rocketmq-dashboard#6110 ·
メンテナーはふだん 4 日以内に返信
-
Feature:Resolution
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
intellij-elixir/intellij-elixir#4396 ·
メンテナーはふだん 1 日以内に返信
-
Python 3.15 support対応中かも @amnesiaof が今日担当しました。 オープンL: python L: python:uv
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
dependabot/dependabot-core#16524 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信