Rules bug?

I have this sequence of rules, but it seems to stop after the 2nd rule:

This is what I get in the end:

I know I can merge some rules, for example renaming to A1 and adding the Red tag all in one rule, but I'm testing different actions for specific workflows and understanding how the app actually works and its limitations, will help me build them more efficiently.

The reason for my confusion is that according to the documentation about rules here:
https://www.noodlesoft.com/manual/hazel/work-with-folders-rules/create-edit-rules/understand-the-logic-of-rules/, Hazel only matches the first rule, not the other ones after that. If that was the case, then the file would be renamed to A1, but it wouldn't add the Red tag, correct? But it's applying the 1st and 2nd rules, but not the 3rd, which is weird.

I would guess that renaming a file makes Hazel assume it's a new file? Is that the case? If so, that would make sense.
But then, what kind of thing would make Hazel assume we are dealing with new files, besides renaming them?

Yes, renaming may end up having the file treated as a new file. But even despite that, if a file is named A1, it will never get past the first rule matching that name. You need to use the Continue action if you want evaluation to continue.

Mr_Noodle wrote:Yes, renaming may end up having the file treated as a new file. But even despite that, if a file is named A1, it will never get past the first rule matching that name. You need to use the Continue action if you want evaluation to continue.

Not sure if my post was clear enough based on what you said "if a file is named A1, it will never get past the first rule matching that name".

When I showed the image of A1.jpg, that was already a renamed file, meaning the original file was called Cover Artwork.jpg, so it ran the 1st rule (renamed it to A1.jpg) and then ran the second rule to apply the Red tag.
So maybe if the name is already A1 it will just run the first rule (if it was for example to add a Green tag first), but not the second one (adding the Red tag), but in this case when it went from Cover Artwork to A1, it then ran the second rule, but stopped there.

Thanks for confirming that renamed files are considered new files, though.

Also, regarding my second question: is there any other thing(s) that would make Hazel assume a file is new, just like renaming it does?

If the file is named A1, it will always match the red tag rule. That rule doesn't rename it and because that rule matches the file first, that file will never get to the rule that renames it to C1.

Mr_Noodle wrote:If the file is named A1, it will always match the red tag rule. That rule doesn't rename it and because that rule matches the file first, that file will never get to the rule that renames it to C1.

I believe you still don't understand my point...
The file was not A1.jpg when I moved it. It was "Cover Artwork.jpg" when I moved it to the folder.
So Hazel had to run the 1st rule to rename it A1.jpg.
According to the documentation, Hazel only runs the first rule and ignores the other ones, unless you add the action to continue running more rules, right?
So this is an exception. The file itself is the same, the only difference is that Hazel, since the name is different, treats the file as a "new" file and so it runs the 2nd rule, as if it's the 1st one being ran on that file, when in reality, it's the 2nd rule on that file. Does that make sense? It's almost like saying that your name is John and if you change your name to Charles, you are now a different human being. Well, you're not. Your name just changed, not your physical body haha

So when the documentation says that Hazel only runs 1 rule per file, it should mention that there are exceptions, for example, when one rule renames the file, because Hazel will see that same file as a new file. To the user, the file is the same, so it might get confusing. It was for me at least.

I understand your point but you are not understanding mine. It doesn't matter if A1 is consider a new file or not; it's a red herring in this case. It will always match the "Add Red tag" rule. It will never reach the "Rename to C1" rule because the "Add Red tag" rule precedes it in the list. The A1 file will always match that rule and stop evaluation. You need to either add a Continue action, re-order the rules or add a condition to check whether the red tag is there already.

If you use the Rule Status feature, you can see that it is matching the red tag rule.

Mr_Noodle wrote:I understand your point but you are not understanding mine. It doesn't matter if A1 is consider a new file or not; it's a red herring in this case. It will always match the "Add Red tag" rule. It will never reach the "Rename to C1" rule because the "Add Red tag" rule precedes it in the list. The A1 file will always match that rule and stop evaluation. You need to either add a Continue action, re-order the rules or add a condition to check whether the red tag is there already.

If you use the Rule Status feature, you can see that it is matching the red tag rule.

"The A1 file will always match that rule and stop evaluation"
Well, so did my first rule and yet, it didn't stop the evaluation

So it does matter how Hazel treats certain files, in this case, if one of the rules is to rename a file, Hazel doesn't stop the evaluation there. It assumes that the file is now "new" on the folder so the next rule (#2) is applied (because now, Hazel assuming it's a new file, fails the evaluation of rule #1, which is "If file is Cover Artwork", because it was then renamed A1).

So again, in your documentation saying that rules stop being evaluated when there's a match, isn't completely true, because if the first matching rule is to rename a file, then another rule on the list can run as well. It's an exception.

"If you use the Rule Status feature, you can see that it is matching the red tag rule"
That would apply to the first rule as well, because the file I moved to the folder was called "Cover Artwork", but that doesn't make Hazel stop the evaluation as per the documentation. So yes, it makes a difference knowing that certain actions change Hazel's behavior and keep evaluating rules.
Also, if I get the A1 file with the red tag and drag it to the 3rd rule, I will most definitely have a green check saying it matches the rule. That isn't a completely good way of seeing if the flow itself will run. It just says it matches that individual rule, but it doesn't say if in the sequence, the rule will be applied.

"You need to either add a Continue action, re-order the rules"
I didn't have to do any of that for it to run rule #1 and then run rule #2, one after another:
Original file was called Cover Artwork.jpg
Matches the first rule and renames it to A1.jpg
According to the documentation, why didn't it stop there if it matched one of the rules already?
It kept running and now applies a second rule, adding the Red Tag.
So far it applied 2 rules, against what the documentation mentions.
But, it stops there, not going to the 3rd rule.

If a file is treated as a new file, it starts at the top of the list. Which means, as stated, it will match the tag rule (that matches first) but not the rename rule. If you see otherwise, please show a screenshot of the rule status indicating this.

Green check mark in the preview means nothing because you bypassed the previous rules. You need to use the rule status.

Let's go through this:
- First rename rule matches "Cover Artwork" to "A1". Evaluation stops.
- "A1" goes through the rule list FROM THE TOP. It no longer matches A1 rule. It matches "Add Red tag" rule. Gets tag added. Evaluation stops.
- Even if run again, evaluation starts from the top and will match "Add Red tag" again, again stopping.

Mr_Noodle wrote:If a file is treated as a new file

But this is exactly my point. The documentation says that once a rule is matched, it stops. Well, not really, and we can see it doesn't. Technically the file itself didn't change. It's the exact same file, using the exact same disk space, in the exact same disk place (or so I assume, at least). So saying that rules only run once if they match a certain condition isn't 100% true and I believe that should be mentioned in the documentation. Just adding something that clarifies that if the file is renamed, Hazel will treat that file as a new file, so people will know that renaming a file will make Hazel keep evaluating any rules after that one.

To me this whole "issue" is not about how Hazel works. It's about the documentation giving a not "accurate" explanation when there's a "loop hole" so to speak. Nothing else

If you are willing to add that to make the documentation a bit more clear, great. If not, we all move on. I'm just trying to share my feedback in the hopes that it will make the documentation a tiny little bit better.

I think you are misunderstanding. During a pass, evaluation will stop. But files may be run again later if anything changes. So renaming a file starts another pass. That pass, like every pass, will start at the top of the list and go down. Whether it is treated as a new file is irrelevant here. You could bump the modification date on the file instead. That will trigger another pass and start evaluation on the file.

Mr_Noodle wrote:So renaming a file starts another pass

So why does renaming a file start another pass, but adding a tag doesn't? Well, because when you rename a file, Hazel will see it as a new file that wasn't there on the first pass, so that goes against what you say here:

Mr_Noodle wrote:Whether it is treated as a new file is irrelevant here

Of course it IS relevant. The fact that you get a file and rename it and Hazel sees it as a new file that wasn't there before on the first pass, makes a huge difference. Now you can argue that "technically" Hazel stops evaluating after each pass. Sure, under the hood that's what's doing. But in terms of workflow for the user, that's not what's happening. I had a Cover Artwork.jpg file and I was able to rename it and then add a red tag by just dragging the file to that folder once. So, again, under the hood is one thing, but what matters is what us, users, see happening and in this case, it is applying 2 rules to the same file. And that is only happening, because being treated as a new file DOES make a difference.

But again, we could debate this forever and it's useless. My whole point was: I see it as a documentation thing that could be improved. If you think you don't want to add that small note, that's ok. This is just my feedback as a user who is trying to improve your product a little bit. If what I'm saying doesn't make any sense to you, please discard it completely and we both move on

I rest my case...

It does not matter. If it wasn't a new file, it would behave the same. You changed the file which causes another pass. As I said, if you modified the file, it would also trigger another pass.

The reason it renamed and added a tag was because the file was modified so another pass was done. That pass added the tag. Are you sure another pass wasn't done? Because if it had, it would have changed nothing because of your rule logic. You seem to keep missing that fact and bending this into a documentation issue.

If you can show me that it is not doing another pass in the logs, then please post that as that is a separate issue. My assertion that another pass won't change anything stands. Your rule logic is incorrect and you need to fix that.