supertag 2.5.11 · macOS · local API on 8262
supertag tag add takes a tag id but not a tag name. Hand it a name it can't resolve and it does
nothing, prints a ! line, and exits 0.
$ supertag tag add -- <nodeId> decision
Added tag to My Node (<nodeId>):
! : Tag not found: decision
$ echo $?
0
The node is unchanged. The header still says Added tag to ....
By id it works, and exits 0 the same way:
$ supertag tag add -- <nodeId> pKEm-8D4yEhR
Added tag to My Node (<nodeId>):
+ decision: Added tag "decision"
$ echo $?
0
Same exit code for "did the thing" and "did nothing." The only difference is + vs ! inside the
body text.
Why I think it's unintended
The same command already exits 1 when the node doesn't resolve:
$ supertag tag add -- ZZZnotarealnode decision
Error [NODE_NOT_FOUND]
Resource not found: http://127.0.0.1:8262/nodes/ZZZnotarealnode/tags
$ echo $?
1
Same command, same kind of failure — an argument that didn't resolve — and one exits 1 while the
other exits 0.
The name isn't obviously bad input, either. supertag schema show -- decision resolves that exact
string to pKEm-8D4yEhR. One subcommand takes the name, another ignores it without saying so.
Why it matters
I run tag writes through a queue that marks a row applied on exit 0. So silent no-ops got recorded
as successes, and nothing anywhere reported a failure.
When I swept the ledger, 3 of 9 tag operations had never applied. Every one was a case where a name
reached tag add instead of an id. The oldest had been wrong for three days before I caught it —
that's the part that bothered me, because there was no signal to catch.
I've worked around it since (resolve names to ids first, then verify by reading the node back), so
I'm not blocked. Filing it because anything else driving the CLI would hit the same thing and might
not go looking.
Suggested fix
Exit non-zero when a requested tag fails to resolve, matching the node-not-found path. Resolving
names the way schema show does would also solve it, if you'd rather go that way — the exit code is
the part that matters for scripting. Happy to send a PR if that's useful, and equally happy to leave
it with you.
Smaller second thing: set-field by field name reports the wrong resource
set-field needs --field-id. Given a field name it fails with NODE_NOT_FOUND, pointing at a
path that ends in the field:
$ supertag set-field -- <nodeId> Confidence 4
Error [NODE_NOT_FOUND]
Resource not found: http://127.0.0.1:8262/nodes/<nodeId>/fields/Confidence/content
Suggestion: Verify the node ID or resource path exists in Tana.
$ supertag set-field --field-id 8miZmkfUaRgB -- <nodeId> Confidence 4
Set field on node <nodeId>
Field: 8miZmkfUaRgB
Value: 4
The node exists, carries the tag, and has that field defined — the id form works on the same node one
line later. The error and the suggestion both point at the node, so I went and verified a node that
was never the problem.
This one fails loudly, which is what counts. The message is what sent me the wrong way.
Open to anyone else who's scripting against the CLI if you've hit either of these differently.
supertag 2.5.11 · macOS · local API on 8262
supertag tag addtakes a tag id but not a tag name. Hand it a name it can't resolve and it doesnothing, prints a
!line, and exits 0.The node is unchanged. The header still says
Added tag to ....By id it works, and exits 0 the same way:
Same exit code for "did the thing" and "did nothing." The only difference is
+vs!inside thebody text.
Why I think it's unintended
The same command already exits 1 when the node doesn't resolve:
Same command, same kind of failure — an argument that didn't resolve — and one exits 1 while the
other exits 0.
The name isn't obviously bad input, either.
supertag schema show -- decisionresolves that exactstring to
pKEm-8D4yEhR. One subcommand takes the name, another ignores it without saying so.Why it matters
I run tag writes through a queue that marks a row applied on exit 0. So silent no-ops got recorded
as successes, and nothing anywhere reported a failure.
When I swept the ledger, 3 of 9 tag operations had never applied. Every one was a case where a name
reached
tag addinstead of an id. The oldest had been wrong for three days before I caught it —that's the part that bothered me, because there was no signal to catch.
I've worked around it since (resolve names to ids first, then verify by reading the node back), so
I'm not blocked. Filing it because anything else driving the CLI would hit the same thing and might
not go looking.
Suggested fix
Exit non-zero when a requested tag fails to resolve, matching the node-not-found path. Resolving
names the way
schema showdoes would also solve it, if you'd rather go that way — the exit code isthe part that matters for scripting. Happy to send a PR if that's useful, and equally happy to leave
it with you.
Smaller second thing:
set-fieldby field name reports the wrong resourceset-fieldneeds--field-id. Given a field name it fails withNODE_NOT_FOUND, pointing at apath that ends in the field:
The node exists, carries the tag, and has that field defined — the id form works on the same node one
line later. The error and the suggestion both point at the node, so I went and verified a node that
was never the problem.
This one fails loudly, which is what counts. The message is what sent me the wrong way.
Open to anyone else who's scripting against the CLI if you've hit either of these differently.