[WIP] [#1573] Enhance degradation handler [Rust, no bindings] by elBoberido · Pull Request #1575 · eclipse-iceoryx/iceoryx2

elBoberido · 2026-04-22T00:56:03Z

Notes for Reviewer

Pre-Review Checklist for the PR Author

Add sensible notes for the reviewer
PR title is short, expressive and meaningful
Consider switching the PR to a draft (Convert to draft)
- as draft PR, the CI will be skipped for pushes
Relevant issues are linked in the References section
Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
Commits messages are according to this guideline
- Commit messages have the issue ID ([#123] Add posix ipc example)
- Keep in mind to use the same email that was used to sign the Eclipse Contributor Agreement
Tests follow the best practice for testing
Changelog updated in the unreleased section including API breaking changes

PR Reviewer Reminders

Commits are properly organized and messages are according to the guideline
Unit tests have been written for new behavior
Public API is documented
PR title describes the changes

References

Relates to #1573

…OperationAndFail'

elfenpiff · 2026-04-23T13:17:00Z

-                    mgmt.channels[channel_id.value()].submission_queue.is_full()
-                        && is_connected
-                        && has_valid_channel_state
+                    if is_connected && has_valid_channel_state {


This maybe break request response. I think the channel state corresponds to the request id and if the channel state changes at all the blocking send operation must be stopped since now a different pending response is using this channel for another request.

But I am unsure - could you try to check if this would be true? As soon as I find a space to concentrate I will try to confirm this but this maybe hard in the next hours.

maybe i am wrong

I take a look into this, but the behavior should be the same as right now

Okay, I checked the logic and it is indeed the same as before regarding to stopping blocking operations. If any of

mgmt.channels[channel_id.value()].submission_queue.is_full()

is_connected

has_valid_channel_state

is false, the wait loop will abort. The only difference is that if all three conditions are true, there is still the possibility that the handler decides to leave the wait loop.

But my initial changes are superfluous, so I change it back to have all three conditions in the same if statement

elfenpiff · 2026-04-23T13:20:34Z

    LoanErrorInternalFailure,
    /// A failure occurred while establishing a connection to the ports counterpart port.
    ConnectionError,
+    /// The request could not be delivered


I think the response side is missing. It is possible that an ActiveRequest is unable to send the ResponseMut to its PendingResponse counterpart.

Here some pictures and context: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/doc/user-documentation/request-response.md

Really? I taught it is guaranteed the the response will always be delivered?

There is no iox2_request_send_error_e in the C bindings or a RequestSendError in the C++ bindings but the response branch of request-response seems to use the generic SendError.

elfenpiff · 2026-04-23T17:12:00Z

        return iox2_request_send_error_e_LOAN_ERROR_INTERNAL_FAILURE;
    case iox2::RequestSendError::ConnectionError:
        return iox2_request_send_error_e_CONNECTION_ERROR;
+    case iox2::RequestSendError::UnableToDeliver:


Isnt here a ResponseSendError missing?

In theory not. I had the assumption that a response can never fail, since there is no overflow for the responses and the queue is as large as the amount of active requests.

See #1575 (comment)

elfenpiff · 2026-04-23T17:17:13Z

-                            }
-                            DegradationAction::Fail => {
-                                fail!(from self, with e, "Unable to establish connection to new sender {:?}.",
+                    DegradationAction::AbortOperationAndFail => {


I really struggle with giving the user that option since this clearly violates the freedom of interference for me. I understand and accept that the user needs to be able to do this. But I would love to have an unsafe enum here or something comparable where a safety section (our term of safety) clearly states that this might break the freedom of intereference and the user must be cautious.

Isn't this the same category of violation the freedom of interference like when the publisher decides not to send data anymore to any subscriber?

It is not the subscriber that is so slow that influences the other subscriber, but an deliberate act of the publisher, like stopping to send samples on Friday.

How about this:

rename AbortDeliveryAndFail to DiscardSampleAndFail and AbortOperationAndFail to DegradeOperationAndFail

DiscardSampleAndFail would discard the sample for the receiver that blocks and try to deliver to the remaining receivers

DegradeOperationAndFail would ignore the broken connection and continue with the remaining ones

in the send call, where the degradation as well as the unable to deliver handler could be called, the degradation error has a higher priority and if both occur, the initial degradation error will be returned

if an EINTR occurs, the DegradeOperationAndFail action will make the call fail immediately

What do you think?

elBoberido force-pushed the iox2-1573-enhance-degradation-handler-rust-part branch 6 times, most recently from e266995 to 651a740 Compare April 23, 2026 05:50

elBoberido self-assigned this Apr 23, 2026

elBoberido added 14 commits April 23, 2026 13:44

[#1573] Make degradtion_callback mandatory

062c584

[#1573] Add degradation_callback to blocking_send

b0c1ea7

[#1573] Add 'DegradationCause'

a0dec1c

[#1573] Move some of the 'DegradationCallback' parameter into a struct

fd5395b

[#1573] Add Rust example for degradation callback

d48f624

[#1573] Rework code for default degradation handler

a04f945

[#1573] Extend 'UnableToDeliverStrategy'

2e29725

[#1573] Extend 'UnableToDeliverAction'

c9bdd6a

[#1573] Add distinct UnableToDeliverHandler

934f490

[#1573] Rename 'DegradationAction::Fail' to 'DegradationAction::Abort…

53c5bc6

…OperationAndFail'

[#1573] Rename 'DegradationContext' to 'DegradationInfo'

9a3b52d

[#1573] Fix example naming

9a433d5

[#1573] Add retries and elapsed time to UnableToDeliverInfo

37cc6b2

[#1573] Fix formatting in Python bindings

74d91e3

elBoberido force-pushed the iox2-1573-enhance-degradation-handler-rust-part branch from 651a740 to 74d91e3 Compare April 23, 2026 11:54

elBoberido commented Apr 23, 2026

View reviewed changes

Comment thread iceoryx2-cal/src/zero_copy_connection/mod.rs Outdated

elfenpiff reviewed Apr 23, 2026

View reviewed changes

elBoberido added 5 commits April 23, 2026 15:54

[#1573] Rework unable to deliver handler setup

57e0931

[#1573] Improve example documentation

6442953

[#1573] Simplify 'UnableToDeliverToReceiverHandler' usage in tests

2feda77

[#1573] Add documentation

f21a039

[#1573] Fix typo

c91f234

elfenpiff reviewed Apr 23, 2026

View reviewed changes

elBoberido added 7 commits April 23, 2026 20:14

[#1573] Fix impl for DegradationFn

57227f6

[#1573] Use member initialization for UnableToDeliverInfo

d2c0e1e

[#1573] More doc fixes

9ca08f6

[#1573] Require 'Send' for 'UnableToDeliverFn' and 'DegradationFn'

2ad0b47

[#1573] Use member initialization for DegradationInfo

76d51ac

[#1573] Simplify blocking_send

3cb5c9d

[#1573] Add tests for blocking_send with unable to deliver handler

c553ffa

elBoberido force-pushed the iox2-1573-enhance-degradation-handler-rust-part branch 2 times, most recently from eb8636c to a40f2f2 Compare April 24, 2026 12:32

elBoberido added 4 commits April 24, 2026 22:22

[#1573] Adjust function name

9e8a9ec

[#1573] Add tests for publisher with unable to deliver handler

68bcd71

[#1573] Add tests for client with unable to deliver handler

76f4f2a

[#1573] Add tests for server with unable to deliver handler

aca9488

elBoberido force-pushed the iox2-1573-enhance-degradation-handler-rust-part branch 2 times, most recently from 212a8fe to 65c730a Compare April 24, 2026 21:44

[#1573] Skip timing test for macOS

a2aa490

elBoberido force-pushed the iox2-1573-enhance-degradation-handler-rust-part branch from 65c730a to a2aa490 Compare April 24, 2026 22:26

Conversation

elBoberido commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Notes for Reviewer

Pre-Review Checklist for the PR Author

PR Reviewer Reminders

References

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elBoberido Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

elBoberido commented Apr 22, 2026 •

edited

Loading

elBoberido Apr 23, 2026 •

edited

Loading