Speeding up bulk x-callback-url?

Hi folks,

I’m trying to send many x-callback requests in a rowto Fantastical, in order to bulk import events into a calendar after doing some planning Drafts. My script looks like this:

const baseURL = "x-fantastical3://parse";

const category_regex = /^\#\s?\w+/
var category = ''

const day_regex = /^\#\#\s?\w+/
var day = ''

const task_regex = /^\-\s?.+/
var task = ''

const replace_regex = /^[#-]+\s?/

for (var line of draft.lines) {
	if (category_regex.test(line)) {
		category = line.replace(replace_regex,'');
	} else if (day_regex.test(line)) {
		day = line.replace(replace_regex,'');
	} else if (task_regex.test(line)) {
		task = line.replace(replace_regex,'');
		parsed_line = category + ': ' + task + ' on ' + day;
		var cb = CallbackURL.create();
		cb.baseURL = baseURL;
		cb.addParameter("add", 1);
		cb.addParameter("s", parsed_line);

and my input text looks like this

## Wednesday
- make some notes
## Thursday
- write some text
- fix some bugs
## Friday
# teaching
## Friday
- teach some students

But the looping, as currently structured, is really slow, even on these four x-callback-url calls. I’ve tried not waiting for a request, but this seems to create a race condition that only actually creates the most recently seen parsed line in Fantastical.

Anyone have any suggestions? Somehow this is really slow, the “Event in Fantastical” action (which uses a single CallbackURL action) seems to be really fast.

Given that you are issuing multiple successive requests, I would think that you would want to include cb.waitForResponse = true and I agree that probably is why Fantastical is picking up the first request - it isn’t queuing them, that’s what you want to do in Drafts.

But if you are not waiting on responses, I’m a little confused as to why it would be running slow. I would expect that Drafts would just fire them off rapidly; if I replace cb.open(); with alert(cb.url);, I see instant returns on pressing OK against your test data.

If you add in the response waiting, how long does it take to process your example draft content?

Yes, that’s exactly right, either I include cb.waitForResponse = true and it runs incredibly slowly, or I exclude it, and it picks the last request and runs quickly (but doesn’t achieve what I want), or include that.

I just ran it against the sample data I provided, and saw the second of the four tasks that get added to the calendar occuring around 1m52, the third around 3m52, the fourth around 5m54, and Drafts declared the action completed at around 7m51.

In short, it seems like there’s about 2 minutes between each x-callback-url call, which makes me wonder if I’m hitting some sort of timeout, rather than a success? This speed obviously isn’t tenable for my goals.

Ah okay, you had not mentioned you had tried it with the timeout already, only that you had tried not waiting - a blurring in the subtlety of the wording an my understanding of the issue I guess. I certainly agree that those timings are far too long and sound like a time out.

In terms of understanding more about what is happening, you can check the success, the status and the results. I think something like this should suffice in place of the cb.open().

if (cb.open())
	//Successful call - see what we got back
	//Unsuccessful - check the status returned

	//Then check what we got back

Maybe see what that gets you in terms of additional information?

You are not using x-callback-url, is likely the problem. x-fantastical3://parse is not an x-callback-url. You are using regular URLs, and Fantastical gets them, but never sends a responce to Drafts - which waits for 60 seconds, then gives up and goes on with the action.

You would need to use the fantastical2://x-callback-url/parse version to get a response see Fantastical URL docs.

Note they do not support x-callback-url on Mac, only on iOS.

1 Like

Quick update here: that code definitely suggests there’s an unsuccessful timeout, the alert(cb.status) returns undefined and the JSON.stringify(cb.callbackResponse) is empty JSON {}.

Probably this is related to the next post below from @agiletortoise, so I’ll try that next.

Are you sure the ‘s’ variable is ok ? Shouldn’t it be ‘sentence’ instead ?

I made it work with ‘sentence’ and the x-callback-url mentionned by Greg without any delay on iOS.

I’d totally missed that you weren’t using an x-callback-url. I’d just assumed that since you got it from a working action that it was fine and never bothered checking :confounded:

As Greg says, that would absolutely account for your time outs.

On iOS
I can get the precise x-callback-url mentioned above (fantastical2://x-callback-url/parse/), using the sentence parameter, to go quickly, but it seems like Fantastical wants to treat them as Reminders, not Events (the “Add button”).

EDIT: this was an issue that I’d missed about calendar accounts not being setup. The macOS slowness issue remains.

On macOS
Using the s parameter and the x-fantastical2://x-callback-url/parse/ URL (following what’s happening here https://actions.getdrafts.com/a/1CM), I’m still seeing substantial slow-downs.

EDIT AGAIN: ugh, I missed @agiletortoise’s bit about x-callback-urls not working on macOS. That’s incredibly frustrating. The documentation on their site is super misleading.

Alright, final overall summary:

  • I can’t read/Flexibits’ documentation is super confusing. My slowdown was on macOS, due to not using x-callback-url (in part because x-callback-URL doesn’t work on macOS, and in part because their documentation is confusing).
  • This absolutely works with the correct x-callback-url scheme on iOS, and is very fast. I’ll just have to integrate iOS into my workflow I guess, to get the functionality I want.
  • Thanks to @agiletortoise, @sylumer, and @scripts4drafts for helping me through this!
1 Like

Might be possible to have a branched action that uses AppleScript on Mac and URLs on iOS.

1 Like

What would happen if you just used the non-x-callback URLs on the Mac and added a 2-3 second artificial delay between successive calls? Basically, give Fantastical enough time to do its thing before you ask it to do the next one.

There’s no window timer to access in Drafts, but you can apply a workaround based on elapsed time for a pausing for a short period.

You could then experiment in reducing the time based on the performance of the app on your machine.

That’s very interesting, I’ll have to play with that! I don’t think I have any of the ThoughtAsylum stuff setup yet, so I’ll have to explore those things.

This might not be at all helpful, but have you looked at the Fantastically Good Event parser action at all? That uses most of the same syntax and writes straight to the calendar using Javascript. Obviously since it processes each line in a Draft you might have to do some modification, but it would work on both platforms and not switch between apps all the time.

I experienced a slow reaction on fantastical side with many requests, too.
I contacted them and they are aware of it but it’s mostly intended behavior.
What I did to dramatically improve the performance was to send the strings I want to parse in fantastical to a shortcut which then splits the text into the single items and uses the fantastical actions in shortcuts to create the new events. This needs less than half of the time

1 Like

Actually super helpful! I’d seen it, but decided to go down the path of writing my own because I needed the parsing. Probably worth learning from what they’re doing though, it works really well on pre-parsed input

@willskaens - What’s the VMware field engineer link for? I’m guessing that it’s either something you meant to add to your profile information or that got pasted in by accident.

1 Like