Cannot copy complex objects from metadata

[xhudaman]

Please fill out these Check-boxes

• I checked for existing similar issues
• I checked that the plugin is up to date
• The issue persists with all other plugins and themes disabled

Plugin Version

1.2.5

This Issue Occurs on

• Windows
• Linux
• macOS
• Android
• iOS

Debug Info

SYSTEM INFO:
	Obsidian version: v1.7.7
	Installer version: v1.4.13
	Operating system: #202405300957~1728589823~24.04~3d61696~dev-Ubuntu SMP PREEMPT_DY 6.9.3-76060903-generic
	Login status: not logged in
	Language: en
	Insider build toggle: off
	Live preview: on
	Base theme: adapt to system
	Community theme: ITS Theme v1.2.88
	Snippets enabled: 2
	Restricted mode: off
	Plugins installed: 8
	Plugins enabled: 8
		1: Meta Bind v1.2.5
		2: JS Engine v0.1.20
		3: CustomJS v1.0.21
		4: Dataview v0.5.67
		5: Iconize v2.14.6
		6: Minimal Theme Settings v8.1.1
		7: Style Settings v1.0.9
		8: Templater v2.9.1

RECOMMENDATIONS:
	Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Describe the Issue

I have 2 frontmatter properties, one called counters that contains a list of objects and the other defaultCounters.

defaultCounters:
  key1:
    slot1: false
    slot2: false
  key2:
    slot1: false
    slot2: false
counters:
  key1:
    slot1: true
    slot2: false
  key2:
    slot1: false
    slot2: true

I am using toggles to display these and created a button template to reset them alongside other values that are tracked. I am including only the relevant actions of this button in the example but there are a few more.

Note

This button is a template created with the builder in the plugin settings

label: ""
icon: moon-star
hidden: true
class: ""
tooltip: ""
id: long-rest-test
style: primary
actions:
  - type: updateMetadata
    bindTarget: counters.key1
    evaluate: true
    value: getMetadata('defaultCounters.key1')
  - type: updateMetadata
    bindTarget: counters.key2
    evaluate: true
    value: getMetadata('defaultCounters.key2')

When running these actions the frontmatter gets updated as follows.

defaultCounters:
  key1:
    &a1
    slot1: false
    slot2: false
  key2:
    &a2
    slot1: false
    slot2: false
counters:
  key1: *a1
  key2: *a2

It looks to me as though it can only ever set the value as a reference to the defaultCounters.key(1|2) values.

I have tried other variations for the value in the templates such as:

• JSON.parse(JSON.stringify(getMetadata(defaultCounters.key1)))
• {...getMetadata(defaultCounters.key1)}
• Object.assign({}, getMetadata(defaultCounters.key1))

Steps to Reproduce

1. Copy the example markdown below and paste it into a note, ensuring to remove the \ escape character from the ```s that wrap the button definition

---
defaultCounters:
key1:
  &a1
  slot1: false
  slot2: false
key2:
  &a2
  slot1: false
  slot2: false
counters:
key1: *a1
key2: *a2
---

\`\`\`meta-bind-button
label: ""
icon: moon-star
hidden: true
class: ""
tooltip: ""
id: issue-test
style: primary
actions:
- type: updateMetadata
  bindTarget: counters.key1
  evaluate: true
  value: getMetadata('defaultCounters.key1')
- type: updateMetadata
  bindTarget: counters.key2
  evaluate: true
  value: getMetadata('defaultCounters.key2')
\`\`\`

`BUTTON[issue-test]`

`INPUT[toggle:counters.key1.slot1]`
`INPUT[toggle:counters.key1.slot2]`
`INPUT[toggle:counters.key2.slot1]`
`INPUT[toggle:counters.key2.slot2]`

2. Press the button and view the resulting frontmatter

Expected Behavior

When the button is pressed the updated metadata value for counters should look like the block below

counters:
  key1:
    slot1: false
    slot2: false
  key2:
    slot1: false
    slot2: false

when defaultCounters is

defaultCounters:
  key1:
    slot1: false
    slot2: false
  key2:
    slot1: false
    slot2: false

[xhudaman]

I would like to add that I am happy to help contribute a fix for this but I have no experience building Obsidian plugins and would need some help getting started.

[mProjectsCode]

I am able to reproduce the issue. This can be fixed from the side of the plugin, but it seems like something that Obsidian should fix from their side. I might open a bug report on the Obsidian forum. In the meantime you can try structuredClone(getMetadata('defaultCounters.key1')).

[xhudaman]

Thanks for the quick response!

I'll give that a try soon when I have my tablet with me and keep you posted on the result.

If you submit the bug on the forum I'd love the link to keep an eye on it. If not let me know and I can report it there instead.

[xhudaman]

So I got a chance to try it and it worked for the example I gave you. That was a simplified version of my actual metadata, wherein my real case has an extra level of nesting under one of the keys. e.g.

counters:
  key1:
    nestedKey1:
      slot1: true
      slot2: false

In this example the defaults is a nested key under counters that mirrors all its siblings with falsey values. When I press the button the tracked values get completely deleted and only counter.defaults plus all the nested keys remained.

Despite it not behaving as expected, it ended up working out as the values are all false and the keys get recreated when toggling the checkbox to checked.

[mProjectsCode]

https://forum.obsidian.md/t/bug-assigning-objects-in-processfrontmatter-causes-yaml-anchors-to-appear-in-the-frontmatter/94041

[xhudaman]

Thanks for sharing the link! Gonna join the forums there so I can also track the upstream issue.

Clicked through the link to the YAML spec and I'd never been aware that YAML has alias nodes. I use YAML frequently outside of frontmatter but it never dawned on me that it was a language feature. The write up you've done there is fantastic and incredibly thorough.

Thank you again for taking the time to address this in such detail!

[mProjectsCode]

This should be fixed in the next plugin release. I worked around this issue by adding some cloning logic that was needed anyways for memorization.

[xhudaman]

Amazing! Thanks a lot!!