Pure Technical Domino

Checking the Search hits so far, I'm seeing a lot of Blackberry hits and will address these in the coming week. I wanted to get started repopulating the site with something near and dear to my heart.

I have moved from working with a normal sized enterprise to one that is fairly large. One of my first major issues was investigating a situation where a client would stop "receiving" mail, although the router showed it moving fine. Later in the day, or maybe another day or so, mail would start to backup in the queue with the message "attempt to perform folder operation on non folder note" showing in the console (log file).

The short term fix was removal of the Inbox, refresh the design to recreate the inbox, then life would be good for a few minutes. The issue was reported to the support organization (you know which one). They started pointing to a duplicate Inbox, which in the long run, came to be true.

However! They pushed for an investigation to the design. It had to be in the design, they insisted to my recollection. Several iterations of the issue made the client every more insistent on a fix. (Amazing that our clients actually want consistent email, but that's another issue).

The issue revolves around the fact that the Router (apparently still so today) looks for a Note named ($Inbox). The Router doesn't look for a Design Note, just a Note. Don't try this at home unless you want to break things. Take a simple Note (message, todo, reply, doesn't matter), add a field named "$Name" and give it a value of "($Inbox)". Save to your mail file, and watch. The first phase, you will stop receiving new messages to your Inbox, and only see them in All Documents. Slowly (depending on the stream) you will start backing up messages in the mail.box(s) on the server. You will see the message "attempt to perform folder operation on non folder note" as the router attempts to deliver to the simple Note that you created.

So, the fix? Get a copy of NotesPeek, and search for $Inbox. Locate the Note, using the information provided (subject, recipients, etc.) Write down any recipients as they are most likely broken also. Remove the Note, remembering to remove it from the trash also.

Report the issue to support! Although they have provided a hotfix, and promised it fixed, I still see it in the wild.

I’ve been tracking down an interesting issue for the past couple of weeks. I guess I’m losing my touch, because after finding the problem, I’m pounding my head against the wall to get some intelligence back in there. So here’s the whole story.

Seems that messages are routed from the mail.box into a particular mail file, then a process moves them into the ($Inbox) folder. The client sees this as the magic of the message being delivered to the Inbox. Each mail file can have one (and only one) agent with the trigger of “Before New mail arrives.” I believe the agent triggers after the message is in the file (consider being in the All Documents view) and before it’s moved into the Inbox. I don’t know that I have hard evidence of that, just a strong feeling. But I digress.

The process that moves the message into the Inbox (some would say that’s the router), appears to look for a field named “$Name” with a value of ($Inbox) on a Note. Now I should take a side trip here, to mention/remind that all entities in a Notes database are notes. Some are design notes, some profile documents, and others regular documents. It seems that when a document gets created with such a field, the process gets confused and will produce the message “Attempt to perform a folder operation on a non-folder note.” I started looking for the issue when the router refused to deliver messages to this mail box, but I also have now seen this where it will deliver, but not place in the inbox.

So, nearly thirty days with an issue open, and I get instructed to use NotesPeek to search under the covers. Doh! I could have saved a whole bunch of time and effort, but didn’t even cross my mind to use NotesPeek. (ARGGgggg).

So to bring a terribly long story to a close. If you get the message “Attempt to perform a folder operation on a non-folder note.” you might want to use NotesPeek to identify all the documents with a $Name field with the value of ($Inbox). Remove all but the real inbox. Create a temporary folder, and move all the Inbox documents there. Delete the real inbox since it’s probably “hosed” anyway. Next, refresh the design so a new inbox comes into the mail file. Move all the inbox documents back, and test.