Bases: `tags` property crashes with "Cannot read properties of null (reading 'charAt')" when frontmatter contains empty list entries

Bug reports
,
1

Steps to reproduce

  1. Create a note with an empty entry in the tags list in frontmatter:
---
tags:
  - 
---

or

---
tags:
  - sometag
  - 
---
  1. In a different file, create a Base with any filter that references the tags property, e.g.
filters:
  and:
    - tags.contains("sometag")

Did you follow the troubleshooting guide? [Y/N]

Yes.

Expected result

The empty/null list entries should be silently ignored / stripped, and the filter should evaluate normally. That would be consistent with how file.tags handles the same data (file.tags works without error on these same notes).

Actual result

Base does not render and error notification appears:

Failed to evaluate a filter: Cannot read properties of null (reading ‘charAt’)

As far as I can tell, the tags property becomes completely inaccessible to the filter. All of these produce the same error:

  • tags.contains("anything")

  • tags.toString()

  • tags.length

  • tags.isType("list")

  • tags.isTruthy()

  • tags.filter(value.isTruthy())

  • tags[0]

  • file.properties["tags"]

However, in the base, the tags are shown correctly (i.e. if I don’t use a filter, the table shows the tags correctly with the null item dropped)

Other methods can access the data without issue, including:

  • file.tags and file.tags.contains() — works fine (but includes inline tags, so it’s not equivalent)

  • file.hasProperty("tags") — returns true correctly

  • note.keys() — lists “tags” correctly

  • note.values() — returns the list including the null entry, without crashing

The issue is isolated to null entires

These don’t produce the error:

  • tags: [sometag, ]

  • tags: [sometag, ""]

  • tags: [sometag, " "]

  • tags: [] (empty list)

  • tags: (no value — property exists but is null, not a list with null)

  • No tags property at all

whereas this does cause the error:

---
tags: [sometag, null]
---

Environment

SYSTEM INFO:
	Obsidian version: 1.12.7
	Installer version: 1.12.7
	Operating system: Darwin Kernel Version 24.6.0: Fri Feb 27 19:34:42 PST 2026; root:xnu-11417.140.69.709.8~1/RELEASE_ARM64_T6020 24.6.0
	Login status: logged in
	Language: en
	Catalyst license: insider
	Insider build toggle: on
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 0
	Plugins enabled: 0

RECOMMENDATIONS:
	none

Additional Information

I came up with a silly work around, which does accomplish what I want it to, but it’s not very user friendly.

filters:
  and:
    - formula.safe_prop_tags.contains("sometag")
formulas:
  safe_prop_tags: note.values()[note.keys().map(if(value == "tags", index, -1)).filter(value >= 0)[0]].filter(value.isTruthy())
2

thanks.

Doesn’t happen with other lists properties.

This likely happens because tags has a special handling.

1 Like
3

Do you want empty tags or are they the product of a script or something and you want to get rid of them? If you’re just trying to get rid of the crazy things, I’d suggest BBedit, which has an adequate free version.

4

I’m just reporting what looks like a bug in the processing of tags data in bases filters. From a pure functionality standpoint, the safe_prop_tags formula already solves the issue.