Inconsistent behavior using $Name(agent) in $AgentQuery

Agents, Actions and Automation Posters
1

Updated to 11.7.0, and just noticed I’m having an issue with a bunch of agents that used to work.

The container “Notes by Category“ holds nine agents, and sets their $AgentQuery by $Edict.

All agents appear to have the same, correct, generic $AgentQuery: inside(Content Notes)&$Categories.contains($Name(agent))

“Content Notes“ currently houses around 3100 notes.

$Categories is a user declared set.

All agents are set to normal priority.

Only the first agent in the container will populate, even given several minutes.

Weirdly, if I insert spurious pairs of open and close parentheses in the $AgentQuery, I can get the number of populated agents to increment by one.

If I disable the edict and replace $Name(agent) with the literal names of the agents, all agents populate quickly and correctly.

Any idea what I’m missing?

2

Might there be more than one note named “Content Notes”?

I don’t see anything obviously wrong above.

3

So, the agent called “foo” should match all notes that are children of container “Content Notes” and whose Set-type user attribute ‘Categories’ includes the value “foo”. What is the Tinderbox version from which you’ve just updated? Depending how old it was, one recent agent-related change was v11.5.0 dropping support for the old #-prefixed query syntax (see more).

Current general syntax convention is to quote note names used for references but not quote full paths. So if “Content Notes” is at path /Something/Content Notes, these alternatives would be used:

inside("Content Notes")
or
inside(/Something/Content Notes)

but I don’t think your current syntax should affect performance.

Given the generic nature of the query, why the need to set it via edict. I ask in case there are wider factors than might affect the seeming immediate problem.

You can tell if the agent cycle is getting hung up by looking at the Agents & Rules Inspector.

It might be useful to see a small test document that shows the problem. It only needs a few notes in ‘content notes’ some of which should match each of the agents. You likely only need 3-4 agents and not the full set. If such a test doesn’t replicate the problem there are probably other features in your file that are the root cause.

4

One other thought. What are the $Name values of the agents. Might they include problematic characters?

5

Checking with a simple agent, and with the attribute brower, I find only one note with that name.

6

Edit: reducing the size led me to an unrelated note with a simple edict to set the note’s badge, and a typo therein. Correcting the typo solved the issue. Thanks for suggesting a reduced document!

The last version where I know for certain the document was working as intended was somewhere in the 10.x. I’m reasonably sure I would have noticed if it wasn’t working when I updated to 11.0, but it’s possible the agents were inactive and I was working from cached values.I could have sworn unquoted name references were preferred for unique note names, but maybe that’s just because *I* preferred having a way to remind myself that certain names were being assumed unique.I’m setting $AgentQuery via $Edict because I’ve got a long history of fat-fingers and getting interrupted mid-thought, leading to incomplete/inconsistent… everything. :smiley:I suspected the parent $Edict process might have been inadvertently interrupting the agents by resetting their queries, so I’ve made sure the edict checks whether the queries need to be set. In any case, disabling the edict doesn’t seem to change anything.All values for $Categories are single English words. Same for the agent names.All names for User Attributes are single English words or camel cased English words.The inspector sits comfortably with 0 pending tasks.I’ll get to work on the reduced document.

1 Like