editTaskLineModal() does not resolve its promise when user clicks Cancel

[legaldrugdealer]

⚠️ Check issue is valid.

• My request is about the Tasks plugin for Obsidian.
• I have tested the bug with the latest version of the Tasks plugin.

⚠️ Check that this issue hasn't been reported before.

• I searched previous Tasks plugin Bug Reports didn't find any similar reports.

Steps to reproduce

1. Open Obsidian with the Tasks plugin enabled.
2. Open the Developer Console (Ctrl+Shift+I / Cmd+Opt+I).
3. Paste and run the following snippet:

const tasksApi = app.plugins.plugins["obsidian-tasks-plugin"].apiV1;
(async () => {
  console.log("[TEST] before modal");
  const result = await tasksApi.editTaskLineModal("- [ ] test");
  console.log("[TEST] after modal:", JSON.stringify(result), "length:", result.length);
})();

4. In the modal that opens:
   Case A: Enter a start date and click Apply → console logs the edited line.
   Case B: Leave out the start date and click Apply → console logs the edited line without 🛫.
   Case C: Click Cancel → console shows [TEST] before modal but never logs [TEST] after modal. The promise never resolves.

Expected Behavior

According to the Tasks API documentation, editTaskLineModal() should always resolve:

• Return the edited line if Apply is clicked.
• Return an empty string "" if Cancel is clicked.

Current behaviour

• Clicking "Apply" with or without start date works as expected.
• Cancel leaves the promise unresolved. No value is returned, and the awaiting code never resumes.

Impact

• Scripts and QuickAdd macros that rely on editTaskLineModal cannot detect someone clicking "Cancel".
• This causes workflows to hang or terminate unexpectedly, since the promise never resolves.

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Operating System Version(s)

11

Obsidian Version

1.9.14

Tasks Plugin Version

7.22.0

Checks

• I have tried it with all other plugins disabled and the error still occurs

Possible solution

Adjust the modal’s cancel handler so that it explicitly calls the promise resolver with "".

[claremacrae]

Thank you for logging this. It seems that clicking outside the modal behaves the same as clicking Cancel.

[claremacrae]

The same behaviour occurs with createTaskLineModal() which is interesting as it has existed for a lot longer, and the issue hasn't been reported before:

const tasksApi = app.plugins.plugins["obsidian-tasks-plugin"].apiV1;
(async () => {
  console.log("[TEST] before modal");
  const result = await tasksApi.createTaskLineModal();
  console.log("[TEST] after modal:", JSON.stringify(result), "length:", result.length);
})();

[claremacrae]

I wound back to an earlier version of the code - b954d24 - and got the same behaviour. At this point, I think that only tasksApi.createTaskLineModal() exists...

[claremacrae]

There is a unit test that claims to test that Cancel returns an empty string:

obsidian-tasks/tests/Api/createTaskLineModal.test.ts

Lines 63 to 71 in b3d753b

	it('should return an empty string if cancelled', async () => {
	const taskLinePromise = createTaskLineModal(app, []);
	const expected = '';
	TaskModal.instance.cancel();
	const result = await taskLinePromise;
	expect(result).toEqual(expected);
	});

[claremacrae]

Final test: I've checked out version 2.0.0, which is when tasksApi.createTaskLineModal() was introduced.

And I get the same behaviour. So it appears that the documented behaviour with clicking Cancel may never have worked, as far as I can see.

That this has not been reported before seems a little surprising, given the number of places that this feature is used in:

https://github.com/search?q=createTaskLineModal+NOT+is%3Afork+NOT+repo%3Aobsidian-tasks-group%2Fobsidian-tasks+NOT+path%3A*.md&type=code

[claremacrae]

Hi @justise, as you kindly wrote the tests of the Modal functions in the Tasks API, and are the most recent person to have worked on the code, would you be able to spare some time to have a look at this issue -

• to see how the tests differ in behaviour from the production code
• and/or to see if you can find a fix for the issue?

[justise]

Yea I can take a look over the next few days.

[justise]

Is it possible to assign it to me?

[claremacrae]

Is it possible to assign it to me?

Done. Many thanks!

[justise]

Found the issue, there's a check for .length thats blocking onSubmit

updatedTasks.length && onSubmit(updatedTasks); // <-- THE BUG!

It's also present in createTaskLineModal()

we can't remove it because that would break existing integrations, so I'm looking at adding a new callback to enable resolution of the promise on cancel.

[claremacrae]

Thank you for this, @justise!