fix(callbacks/v2): OnTimeoutPacket blocked by UnmarshalPacketData error#8856
Merged
srdtrk merged 4 commits intocosmos:mainfrom Mar 26, 2026
Merged
Conversation
…utPacket OnTimeoutPacket propagates UnmarshalPacketData errors, blocking the packet timeout lifecycle. This is inconsistent with OnSendPacket (line 124) and OnAcknowledgementPacket (line 254), both of which return nil on the same error, allowing the packet lifecycle to continue unblocked. The inconsistency is also visible in the comments: - OnSendPacket: "is not blocked if the packet does not opt-in to callbacks" (line 123) - OnAcknowledgementPacket: same comment (line 252) - OnTimeoutPacket: comment was missing (now added) The V1 callbacks middleware does not have this inconsistency because it uses a different pattern (GetSourceCallbackData combining unmarshal and callback data extraction). Impact: If a packet's payload cannot be unmarshalled by the callbacks middleware (e.g., codec version mismatch), the timeout transaction reverts entirely. The underlying app's OnTimeoutPacket has already executed the refund (line 317-320), but the revert rolls back all state changes. Since the packet has already timed out on the destination chain and cannot be received, the sender's funds become permanently locked with no recovery path. This aligns with the principle stated at line 359: "callback execution errors are not allowed to block the packet lifecycle."
srdtrk
changed the title
srdtrk
approved these changes
Mar 26, 2026
mergify bot
pushed a commit
that referenced
this pull request
Mar 26, 2026
…or (#8856) * fix(callbacks/v2): return nil on UnmarshalPacketData error in OnTimeoutPacket OnTimeoutPacket propagates UnmarshalPacketData errors, blocking the packet timeout lifecycle. This is inconsistent with OnSendPacket (line 124) and OnAcknowledgementPacket (line 254), both of which return nil on the same error, allowing the packet lifecycle to continue unblocked. The inconsistency is also visible in the comments: - OnSendPacket: "is not blocked if the packet does not opt-in to callbacks" (line 123) - OnAcknowledgementPacket: same comment (line 252) - OnTimeoutPacket: comment was missing (now added) The V1 callbacks middleware does not have this inconsistency because it uses a different pattern (GetSourceCallbackData combining unmarshal and callback data extraction). Impact: If a packet's payload cannot be unmarshalled by the callbacks middleware (e.g., codec version mismatch), the timeout transaction reverts entirely. The underlying app's OnTimeoutPacket has already executed the refund (line 317-320), but the revert rolls back all state changes. Since the packet has already timed out on the destination chain and cannot be received, the sender's funds become permanently locked with no recovery path. This aligns with the principle stated at line 359: "callback execution errors are not allowed to block the packet lifecycle." * docs: added deleted comment * docs: added CHANGELOG entry --------- Co-authored-by: srdtrk <srdtrk@hotmail.com> (cherry picked from commit 0e8a117) # Conflicts: # CHANGELOG.md
srdtrk
added a commit
that referenced
this pull request
Mar 26, 2026
…or (backport #8856) (#8870) * fix(callbacks/v2): OnTimeoutPacket blocked by UnmarshalPacketData error (#8856) * fix(callbacks/v2): return nil on UnmarshalPacketData error in OnTimeoutPacket OnTimeoutPacket propagates UnmarshalPacketData errors, blocking the packet timeout lifecycle. This is inconsistent with OnSendPacket (line 124) and OnAcknowledgementPacket (line 254), both of which return nil on the same error, allowing the packet lifecycle to continue unblocked. The inconsistency is also visible in the comments: - OnSendPacket: "is not blocked if the packet does not opt-in to callbacks" (line 123) - OnAcknowledgementPacket: same comment (line 252) - OnTimeoutPacket: comment was missing (now added) The V1 callbacks middleware does not have this inconsistency because it uses a different pattern (GetSourceCallbackData combining unmarshal and callback data extraction). Impact: If a packet's payload cannot be unmarshalled by the callbacks middleware (e.g., codec version mismatch), the timeout transaction reverts entirely. The underlying app's OnTimeoutPacket has already executed the refund (line 317-320), but the revert rolls back all state changes. Since the packet has already timed out on the destination chain and cannot be received, the sender's funds become permanently locked with no recovery path. This aligns with the principle stated at line 359: "callback execution errors are not allowed to block the packet lifecycle." * docs: added deleted comment * docs: added CHANGELOG entry --------- Co-authored-by: srdtrk <srdtrk@hotmail.com> (cherry picked from commit 0e8a117) # Conflicts: # CHANGELOG.md * docs: fix conflict --------- Co-authored-by: Mefai <95135443+mefai-dev@users.noreply.github.com> Co-authored-by: srdtrk <srdtrk@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OnTimeoutPacket propagates UnmarshalPacketData errors, blocking the packet timeout lifecycle. This is inconsistent with OnSendPacket (line 124) and OnAcknowledgementPacket (line 254), both of which return nil on the same error, allowing the packet lifecycle to continue unblocked.
The inconsistency is also visible in the comments:
The V1 callbacks middleware does not have this inconsistency because it uses a different pattern (GetSourceCallbackData combining unmarshal and callback data extraction).
Impact: If a packet's payload cannot be unmarshalled by the callbacks middleware (e.g., codec version mismatch), the timeout transaction reverts entirely. The underlying app's OnTimeoutPacket has already executed the refund (line 317-320), but the revert rolls back all state changes. Since the packet has already timed out on the destination chain and cannot be received, the sender's funds become permanently locked with no recovery path.
This aligns with the principle stated at line 359: "callback execution errors are not allowed to block the packet lifecycle."