DPL: fix routing issues in forwarding #14859
Open
+84
−149
Conversation
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
Contributor
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
ktf
changed the title
ktf
changed the title
Member
Author
|
@shahor02 @davidrohr @Barthelemy @knopers8 this might explain some of the issues you have seen in async reconstruction of pp data on the EPN. There was for sure some flawed logic, I am not sure if it could be triggered in normal circumstances apart from EoS or multi proxy setups when wildcards are involved. Unless you are 100% happy with this, I want to first write a unit test for the new forwarding logic to make sure all my assumptions are correct. |
davidrohr
reviewed
Nov 28, 2025
| // We need to find the forward route only for the first | ||
| // part of a split payload. All the others will use the same. | ||
| // but always check if we have a sequence of multiple payloads | ||
| cachedForwardingChoices.clear(); |
Collaborator
There was a problem hiding this comment.
I don't understand, how does the caching work for multi-parts now?
Member
Author
There was a problem hiding this comment.
I renamed the variable to avoid confusion. I think the ability to cache the forwarding choice was either wrong or only correct in a past where wildcards were not there. To exemplify:
- Assume you have a wildcard InputSpec for
SRC/*. - This will match
SRC/AandSRC/Band put them in the same messageSet. - There is no guarantee that both
SRC/AandSRC/Bare to be sent to the same place.
The above only worked so far because I assume in general a wildcard is used for sinks and therefore it is last.
For multiparts, it is enough to iterate over the messageSet.getNumberOfPayloads(pi) as it's done later in the code.
Member
Author
There was a problem hiding this comment.
Ok, I see what you mean now. You are talking about the split payloads in the form:
[Header1][payload0][header1][payload1]... etc
indeed for those I need to have the cache to stay around in the new version... Will do it in a bit.
Member
Author
There was a problem hiding this comment.
Updated with the old logic and improved description.
ktf
force-pushed
the
pr14859
branch
2 times, most recently
from
1677bb0 to
57e7546
Compare
Collaborator
|
Error while checking build/O2/fullCI_slc9 for 57e7546 at 2025-11-29 22:54: Full log here. |
ktf
changed the title
Collaborator
|
Error while checking build/O2/fullCI_slc9 for aa79411 at 2025-12-08 15:06: Full log here. |
Use a single helper function to improve readability.
If one (header, payload, ...) tuple in a MessageSet was to be copied, all the subsequent ones would have been copied. If one (header, payload, ...) tuple got redirected to more than one destination, all the subsequent ones would have been redirected there.
This was referenced Dec 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
If one (header, payload, ...) tuple in a MessageSet was to be copied,
all the subsequent ones would have been copied.
If one (header, payload, ...) tuple got redirected to more than one destination,
all the subsequent ones would have been redirected there.
Stack created with Sapling. Best reviewed with ReviewStack.