[ 
https://issues.apache.org/jira/browse/NIFI-15501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054435#comment-18054435
 ] 

Mark Ward edited comment on NIFI-15501 at 1/26/26 8:57 PM:
-----------------------------------------------------------

[~dstiegli1], indeed I have.

Here's my MRE/test flow:

!image-2026-01-26-20-40-08-255.png|width=396,height=302!

 

GenerateFlowFile outputting a mock-csv with appropriate non-compressed mime 
type:

!image-2026-01-26-20-40-44-013.png|width=600,height=510!

ModifyCompression:

!image-2026-01-26-20-41-07-076.png|width=565,height=234!

 

In this case the FlowFile is routed to Failure.  No bulletin/error is raised, 
which as an aside is the usual behaviour when a FlowFile is routed to a failure 
queue.

The CompressContent did behave this way, instead it routes the FlowFile to the 
success queue (which to be fair might not be what another user would may want - 
perhaps they would prefer it to fail if the non-compressed file is processed).

It's also worth noting the CompressContent mentions this behaviour in it's 
description but I don't see the same mentioned in ModifyCompression - apologies 
if I've missed it.

Hope this helps.

_Edit: Spelling_


was (Author: _mark_):
[~dstiegli1], indeed I have.

Here's my MRE/test flow:

!image-2026-01-26-20-40-08-255.png|width=396,height=302!

 

GenerateFlowFile outputting a mock-csv with appropriate non-compressed mime 
type:

!image-2026-01-26-20-40-44-013.png|width=600,height=510!

ModifyCompression:

!image-2026-01-26-20-41-07-076.png|width=565,height=234!

 

In this case the FlowFile is routed to Failure.  No bulletin/error is raised, 
which as an aside is the usual behaviour when a FlowFile is routed to a failure 
queue.

The CompressContent did behave this way, instead it routes the FlowFile to the 
success queue (which to be fair might not be what another user would may want - 
perhaps they would prefer it to fail if the non-compressed file is processed).

It's also worth noting the CompressContent mentions this beviour in it's 
description but I don't see the same mentioned in ModifyComptess - apologies if 
I've missed it.

Hope this helps.

> ModifyCompression should route incoming uncompressed FlowFile appropriately 
> when Input Compression Strategy is 'use mime type attribute'
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-15501
>                 URL: https://issues.apache.org/jira/browse/NIFI-15501
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>    Affects Versions: 2.6.0
>         Environment: Windows Server 2022
>            Reporter: Mark Ward
>            Priority: Minor
>         Attachments: image-2026-01-26-20-40-08-255.png, 
> image-2026-01-26-20-40-44-013.png, image-2026-01-26-20-41-07-076.png
>
>
> ModifyCompression replaces the deprecated (as of 2,6.0) CompressContent.
> CompressContent had a useful feature, the documentation explains:
> {quote}A common idiom is to precede CompressContent with IdentifyMimeType and 
> configure Mode='decompress' AND Compression Format='use mime.type attribute'. 
> When used in this manner, the MIME type is automatically detected and the 
> data is decompressed, if necessary. If decompression is unnecessary, the data 
> is passed through to the 'success' relationship.
> {quote}
> In contrast, ModifyCompression does not behave this way, instead routing 
> FlowFiles to the failure relationship (note this does not raise an 
> error/bulletin).
> Can the ModifyCompression be modified to optionally include similar 
> behaviour.  Perhaps routing files to a separate queue if user transparency is 
> is of high importance. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to