File.tags returns tag strings with # prefix, but docs don't mention it (causes silent filter failures)

Hi everyone,

While building a Bases filter to show only notes tagged #todom (excluding nested tags like #todom/shoping), I ran into a silent failure that took a while to debug. Posting here as it looks like a documentation bug — or possibly a behavior inconsistency worth fixing.

Steps to reproduce

Create notes with nested tags: #todom/shoping, #todom/proj and some with only #todom.
Create an embedded base code block with a formula using file.tags:

filters:
  and:
    - file.hasTag("todom")
formulas:
  noSubtag: file.tags.filter(value.startsWith("todom/")).isEmpty()
views:
  - type: table
    name: test
    order:
      - file.name
      - file.tags
      - formula.noSubtag

yaml
Observe the noSubtag column.
Did you follow the troubleshooting guide? Y

Expected result

noSubtag = true for notes tagged only #todom
noSubtag = false for notes tagged #todom/shoping, #todom/proj, etc.

Actual result

noSubtag = true for all files — formula silently fails, no error shown.

Root cause discovered by trial and error:
file.tags returns strings with # prefix: [“#todom/shoping”, “#noai”]
So value.startsWith(“todom/”) never matches — strings start with #, not t.

Workaround — add # to the pattern:

file.tags.filter(/^#todom//.matches(value)).isEmpty()
Environment
[debug info]

Additional information

The Bases functions docs describe file.tags as: “The tags for this file. Includes inline tags.” — no mention of # prefix.

file.hasTag(“todom”) accepts names without #. This silent inconsistency between file.tags and file.hasTag() is the bug.

Thanks for looking into this!

Good catch. I’d also make the workaround explicit with a prefix test, e.g. value.startsWith("#todom/"), so it is clear the returned values are display-style tags while file.hasTag("todom") normalizes the input. The main problem is the silent failure: if Bases can’t warn here, the docs should probably say that file.tags returns the literal #tag strings.