Troubleshooting Assistance

Captain’s Log, my “daily notes” file has been working reliably for over a year, automatically generating new Day containers, and executing a function that gathers upcoming events from the Calendar app and places them in a note as the first entry in a new Day container.

Since Tuesday, the Month container has not been firing the edict to generate a new day.

I’ve used Run Now in the Inspector, and it still doesn’t run.

As part of my initial troubleshooting, and to prepare to submit a copy of the file without any data, I duplicated Captain’s Log in Finder, renamed it and opened it.

Everything worked. It created the 2025 container, which created the June container, which created the Thursday container, which launched the function to create the Midwatch entry.

Head scratcher.

I closed the working copy of Captain’s Log and re-opened it, not out of some insight, knowledge or experience, just as a kind of “jiggle the cable,” effort.

No change.

Now, this is odd, because, apart from the data, the nearly-empty prototype document is otherwise identical to the one that isn’t working. So it wouldn’t help to send along that file, because it works.

It’s early in the month, and I haven’t created many entries in June, preoccupied with other matters, so I may just delete June and see if the Year container creates June, and if June then works as intended.

But I’m easter-egging here. Is there something that might be more revealing I might try? Again, the edict in the Month container isn’t working, and Run Now won’t compel it to run.

Thanks.

Further to the foregoing…

While brushing my teeth, it occurred to me that perhaps there was a defect in the logic and there was a conflict with an existing note, thinking perhaps I started the log in June of 2024.

That would have been too easy. The log began in March 2024, and it had no issues with March, April or May 2025 and did create June 2025 and the first couple of entries.

Update: I deleted June and the 2025 container created the June 2025 container, but nothing works after that. Here are the file stats from the Document pane of the Inspector (+1 to TextSniper for capturing this text):

Notes 986 Words 35,518
Agents 6 Links 11
Aliases 176 Attributes
Adornments 0 System 423
Total 1,168 User 3
Prototypes 15
Templates 5

I’ll upload the prototype Captain’s Log document if anyone cares to examine the edict in context.

You can delete the existing containers, and everything will run except the function because you won’t have the Automator application, and then there are the usual privacy and security hoops you’d have to jump through to get it to work.

Captain’s Log Prototype.tbx (275.9 KB)

A few thoughts…

One thing to look at—and to avoid chasing what-ifs—is to look at the Agents & Rules tab of the Tinderbox Inspector:


If progress bar on the the agents or rules tell-back isn’t working or progress isn’t sent on the circular tellback at the bottom, it is a sign that something is amiss. If rules or agents stop at a particular point that rule (agent (or the one preceeding in in $OutlineOrder) merits a quick look. If the bottom cycle is jammed, something is having a very long thing. IOW, the edict not ‘running now’ is because its on athe end of a long queue of things wanting to ‘run now’. The edict can run until the queue for the run now queue drains.

I’m oversimplifying deliberately to make the point: the ship is indeed flooding but the hull breach might not be in the compartment we are watching flood.

In your main doc, if you aren’t adding any new content then all (most?) code runs to a result of no-change’. So assuming the main rules/edicts are set in prototypes, then you could temporarily remove those actions from the prototypes and see if the action/agent cycles starts running again. If so, then swap in out one prototype’s actions at a time (same for agents). If you are lucky, this may localise the badness to one action, albeit not to the note with the problem.

It also means that in, in the this ‘steady state’ any (cause of) badness has likely already happened so notes recently created or altered warrant a hard stare as being the casue of the malaise.

Also review the actions. For instance did you make a note with a $Name that made sense in the context but on reflection will upset the parsers. Recall to that the cause of the blockage may be upstream (up-cycle) of where you think it occurs.

Also ‘just’ pasting content from webpages into $Text a long-time source of unexpected hilarity. Friends encourage freinds to always use Paste-And-Match-Style (Cmd+Opt+Shft+V) not Paste (Cmd+V).

1 Like

Another thing I like to try in these situations is to add an obvious diagnostic step to the rule or edict. For example, if the edict is $MyString=explain($Path(this)), I might try

$Color="red";
$MyString=explain($Path(this));
$Color="green";

If the note turns red and stays red, we know the function call is getting stuck. If the note doesn’t change color, we know the action isn’t being performed at all. This is pretty much the simplest thing that could possibly fail, and should give you some more information about what’s not working.

1 Like

We worked on this issue at today’s meetup, and we were able to identify the cause of the issue, and a solution.

create now may require a $Path component to place the newly created note in the proper container.

create will create a new note without a specified $Path; but Tinderbox will examine the outline hierarchy and place the new note in the first container within the hierarchy that seems to match the intended location.

In this case, the edict was running, and creating a new note for each day in June 2025, only it was placing those notes in the June 2024 container.

The solution was to rewrite the edict to explicitly include the $Path of the new note:

if($Created.month == date("today").month)

{
$MyDate=date("today");

$MyString=$MyDate.format("W, L");

var:string newNote= $Path+"/"+$MyString;
create(newNote);
if($MyDate.weekday>5)
{
   $Color(newNote) = "red"; // it's a weekend day!
} else {
   $Color(newNote) =; // it's a weekday
}

}
if($Created.month != date("today").month) $EdictDisabled;

The video will show some worthwhile troubleshooting tips.

2 Likes