Possible workarounds for incompatibility between Templater plugin and PATCH on new periodic note?

[marcaddeo]

When doing a PATCH on my daily note to append content after a heading, if the note does not exist the content that should be appended gets overwritten on templater execution.

I'm not really sure if the bug exists here, or within the Templater plugin tbh. But here's what I'm seeing when I set a breakpoint and step through the code.

1. I use the rest api to run the open daily periodic note command (I started doing this to try and workaround the issue with just doing the PATCH)
2. My breakpoint triggers on the new file creation, and I can see an empty file with a name of 2024-10-03 as expected.
3. Next, the file has it's unparsed template put into place.
4. Then, my content from the PATCH append request is added to the unparsed template file.
5. Templater runs, removing the PATCHed content and leaving you with an empty templated daily note file.

I saw PATCH originally had issues with creating the periodic note and the solution was to wait for the metadatacache to have the file to ensure it's been created. Should this possibly also wait until templating of the file has completed?

Do you think this is more of a bug with Templater? Seems sort of like a race condition between the two plugins, but it's hard to tell.

[coddingtonbear]

I'm afraid this does sound like a race condition, but I'm sorry to tell you that I think this is more of a plugin incompatibility than a bug. I'm unfortunately not aware of any functionality in Obsidian's API that might allow either this plugin or Templater to "lock" a file to prevent other plugins from attempting to make simultaneous writes.

For further context: these are the lines responsible for the entirety of reading the file data in, applying your patch, and writing out the output:

obsidian-local-rest-api/src/requestHandler.ts

Lines 437 to 451 in ecea4e7

	const fileContents = await this.app.vault.read(file);
	const fileLines = fileContents.split("\n");
	const splicePosition = getSplicePosition(
	fileLines,
	position,
	insert,
	aboveNewLine
	);
	fileLines.splice(splicePosition, 0, req.body);
	const content = fileLines.join("\n");
	await this.app.vault.adapter.write(path, content);

. There's really not a whole lot going on there, and although there are possible workarounds for the opposite problem¹, I'm not aware of any way for us to prevent Templater from overwriting your PATCH changes.

Since this is probably a problem unique to your particular use of Templater with daily, automatically-created notes, I'm afraid all I can suggest off-hand is that you maybe find some way of ensuring that Templater runs before the PATCH takes place. Although I use this plugin's PATCH operation every single day, I don't happen to use Templater myself ever; so I'm not sure what options might be available around that.

That all being said, there are possibly forward-looking technical solutions to this, but I'm afraid none of them would start here:

• You could find out that I'm wrong and that there is an Obsidian API that allows a plugin to "lock" a file it's making modifications to, and then make sure both Templater and this library (I'd accept a PR) use that API so as to prevent this kind of race condition.
• You could post a PR to Templater to implement the approach I mention in ¹ below?

I know this isn't the answer you're hoping for, but I'm not sure there's any immediately-obvious solution that involves changes to this library, so I'm going to convert this issue to a discussion. Definitely feel free to let me know, though, if you can think of some options I haven't considered, though 🤷 .

Footnotes

1. If this plugin were overwriting the changes from Templater, we could monitor the file timestamp to see if it changes between the beginning and end of https://github.com/coddingtonbear/obsidian-local-rest-api/blob/ecea4e78c297e43de258d4537c9f6473b60c2fcf/src/requestHandler.ts#L437-L451 . It's important to note that this wouldn't fix the problem entirely, though, because there could still be changes between when we compare the timestamps and actually finishing the write operation! ↩ ↩²