My external render takes a long time, options?

Developers Central
1

Hi Coda Developers Central,

I made a rendering service of sorts, and wrote a Coda Pack to talk to it. The issue I’m facing is that sometimes it takes quite a while to generate my resulting image, and my Coda Pack will time-out after 50 seconds or so and stop listening.

So I thought of trying to have my Coda Pack call my endpoint, I do the rendering, and then I call back the Coda Pack at some point in the future when it finishes:

  • Coda Pack receives an initial response of: “Received, waiting for render…”
  • Using invocationToken? To let my endpoint ‘‘follow-up’’ to manually call my Coda Pack back in the future, to receive the result.

My issue is: I will want public users to eventually use the Coda Pack hopefully. How long does the invocationToken last for, so that my endpoint can make a call back to the Coda Pack to send the result into the Doc, and update it… skipping the timeout issue?

Sometimes the renderings can be quite complex, and it could take 1-3 minutes for it to finish.

Thanks!

1 Like
2

Hey!

The timeout is indeed 60 seconds for a pack function invocation. As far as I know (unless something changed in the last year, which I highly doubt), there’s no way to ‘call back’ the Pack from your backend. Pack functions are purely request/response from the Coda doc. The only ‘callback’ setup that’s possible with Coda is for your backend to call back to the doc through a webhook automation, but I doubt that it’s what you want.

I’m not aware of any continuation functionality that’d involve invocationToken — AFAIK it’s a token that exists there for technical reason and not for developers to do anything with it. What you probably mean is the continuation of a sync table. That can indeed be used to transcend the 60s limit and let Coda retry a function. But it’s only available in sync tables, and trying to use that as a workaround… well, I wouldn’t do it.

The best solution would probably be this. Implement separate actions:

  • Start the rendering job — should return some Job ID from your backend.
  • Get job status — immediately returns whether the job is completed or not.
  • Get result image — this one would return the image when the render is complete.

Then instruct your pack users to implement an action that would repeat the checks and wait. You can code a button that keeps clicking itself at some 5 second delay until the condition is met (the job is complete) and the loop breaks.

5 Likes
3

+1 to @Paul_Danyliuk’s comment. While the execution times out at 60 seconds, I recently learned (and documented) that fetcher requests timeout at 50 seconds.

Another pattern you could experiment with is using a webhook-triggered automation. It could look like:

  • User creates a webhook-triggered automation, which expects a JSON body containing the request ID and the resulting image URL. The automation does something with that (likely adds it to a table).
  • The user adds the Pack action to their doc, passing the webhook URL as a parameter. They also optionally pass a request ID of their choice, in case they want to match up the webhook with a given row, etc.
  • The Pack kicks off the async job to create the image.
  • The web server creates the image, and when complete triggers the webhook.

It requires a bit of manual setup from the user, and I don’t recall seeing this pattern in use in any other Packs, but it should work in theory.

3 Likes
4

Hi Paul and Eric,

Thank you both for the answers. I re-worked my app backend to handle a polling system like you’ve described. It seems to working, and seems to be faster than doing everything in-line. I had to make my requests with some different ways async.

I have 2 buttons now:

  1. Starts the request to start a job render, saves a token string I give back to Coda in a new table column, for safety of getting the rendering
  2. Requests the status of the job, and returns the image if it’s built yet, otherwise it puts a processing.jpg image

I think it’s working now and seems faster after I forgot to adjust the built-in Rate Limits haha!

Thanks for the replies, I think it’s solved with those ideas!

2 Likes