Skip to content

#1699 - More corrections for WIS2 (2026/06/16)#1718

Open
andreleblanc11 wants to merge 1 commit into
developmentfrom
issue1699
Open

#1699 - More corrections for WIS2 (2026/06/16)#1718
andreleblanc11 wants to merge 1 commit into
developmentfrom
issue1699

Conversation

@andreleblanc11

Copy link
Copy Markdown
Member

This PR addresses 2 things.

  1. I made an error in d55997f. That whole if block only gets invoked when messageDebugDump is used in the configuration.. and I was using the option while testing. I was confused why the headers['content-type'] gets set inside of that if block so I just moved it all out and added debug logging.

  2. There's a problem when we receive the data_id field 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_id field 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_id field from the message at least until we can confirm the messages don't get forwarded to v2 post configs.

amqp_ss_maxlen = 253

I created a plugin so that the field gets dropped.

import logging
from sarracenia.flowcb import FlowCB

logger = logging.getLogger(__name__)

class Remove_long_wis2_fields(FlowCB):

    """
    Remove the message fields that come in from WIS2 brokers that are too long to be posted in v2 format.

    Context:
        We already have a work-around in place in the sr3 source code for the v02 post format to handle header fields that are over the AMQP limit (255 chars).
        However, in sarra v2, there is no workaround. The code will truncate the field if it is to long AND will drop the message before it being posted.
           v2 source code reference: https://github.com/MetPX/sarracenia/blob/4b19896921460971049d43c8674d85ab78a89c7e/sarra/sr_message.py#L756-L769

        For the v3 post format, this isn't a problem because we aren't adding these additional options as headers in the AMQP messages.

        Current WIS2 fields that are being removed due too their length being an issue:
            data_id

        Once we know WIS2 messages don't get propogated to v2 sarra, we theoretically would be able to remove this plugin from the WIS2 data source.
    """

    def __init__(self, options, logger=logger):
        super().__init__(options,logger)

    def after_accept(self, worklist):
        for msg in worklist.incoming:
            if 'data_id' in msg:
                msg['_deleteOnPost'] |= set(['data_id'])

@github-actions

Copy link
Copy Markdown

Test Results

360 tests   359 ✅  1m 42s ⏱️
  1 suites    1 💤
  1 files      0 ❌

Results for commit 472e19f.

@reidsunderland reidsunderland left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants