#1699 - More corrections for WIS2 (2026/06/16)#1718
Open
andreleblanc11 wants to merge 1 commit into
Open
Conversation
Test Results360 tests 359 ✅ 1m 42s ⏱️ Results for commit 472e19f. |
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
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.
This PR addresses 2 things.
I made an error in d55997f. That whole
ifblock only gets invoked whenmessageDebugDumpis used in the configuration.. and I was using the option while testing. I was confused why theheaders['content-type']gets set inside of thatifblock so I just moved it all out and added debug logging.There's a problem when we receive the
data_idfield from the WIS MQTT broker. Often times, it exceeds the 255 char limit invoked for AMQP headers and, when posting in v02 format, causes the post to fail and get retried. I changed the code to continue instead of failing a post when a header field went missing, but that logic might be there on purpose? The change I'm porposing might be doing more harm then good.. don't know.Ideally, we'd want to forward the
data_idfield to downstream clients if possible. It would show them where the WIS2 data source for the product lies and we might be able to leverage it in other ways.I just learned that in the sarra v2, the max char length imposed for AMQP headers in the code is set to 253 chars. So we'll actually need to drop the
data_idfield from the message at least until we can confirm the messages don't get forwarded to v2 post configs.sarracenia/sarra/sr_message.py
Line 46 in 4b19896
I created a plugin so that the field gets dropped.