Content repository applies backpressure even when archiving disabled

When specifying `nifi.content.repository.archive.enabled` to false, I expect NiFi to not do any archiving activities, despite I would have some archiving related configurations set in my properties file.

For example, for this configuration subset

nifi.content.repository.archive.max.retention.period=1 hours
nifi.content.repository.archive.max.usage.percentage=50%
nifi.content.repository.archive.enabled=false 

I would expect NiFi to just delete the claim and not doing any archiving activity.

However, with that exact configuration, I can see in logs some stuffs like

2022-04-06 07:25:02,234 INFO [Timer-Driven Process Thread-54] o.a.n.c.repository.FileSystemRepository Unable to write to container default due to archive file size constraints; waiting for archive cleanup

or 

INFO [Cleanup Archive for default] o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0 bytes) from archive 

I ended up wondering why this could happen.
So I dig a little bit in "FileSystemRepository" class and found the following

Here We can see that the property "nifi.content.repository.archive.enabled" determines the variable "archiveData".

But here we can see that the containerState created with "archiveEnabled = true" is only determined by maxArchiveRatio > 0D, no matter the value of archiveData.

So if we disabled the archiving but left the property "nifi.content.repository.archive.max.usage.percentage" set (which would lead to compute "maxArchiveRatio"), then the containerState will be started with archive enabled.

This line

if (maxArchiveRatio > 0D) { 

should better be

if (archiveData && maxArchiveRatio > 0D) {