C# to coda api timing issue?

[hector_p]

hi there!

i’m having some trouble with the api and get/post requests and timing issues and had reached out to support - they recommended i post here to get some feedback. as i write this, i realize it’s not a c# specific issue (at least i don’t think), so i apologize in advance.

tl;dr: how long does it take for a change in a table to reflect in a GET request?

the message i sent to them:

hi luis! good morning. yes, i’m having trouble understanding timing when using the api to update a row, and to getting a row.

say i have a table, with column name datawritten that is of type checkbox.

i can post, and update that checkbox to true. i can then “get” that row, and see that it’s been updated to true.

the issue i’m facing is that i go to reset the checkbox back to “false” (manually), then when i go to read the table again, it’s still showing the old, i’m guessing, cached value of true. i feel like i’ve waited 30s, 1m, and up to maybe 2min, before, and still see the issue.

i have not quite figured out how long it takes for the api to get the updated value from the table and it’s really problematic for my particular scenario.

i’m not doing many requests either, it’ll probably be less then 50 at most in an hour, i’d say.

right now, i’m just doing testing with my application trying to figure out how to get the rest api working properly so it’s at most only a few requests while i’m debugging my app.

sorry for the longwinded question/answer. hopefully it all makes sense.

thanks in advance for any, and all help

API, Workflows, Integrations and all things built on Coda

[Eric_Koleda]

Hi @hector_p - The unfortunate answer is that a delay of 30 seconds to a few minutes is likely the API working as intended. This delay is due to the underlying architecture, and it tends to be longer for larger, more complex docs.

Two ways to work around it are:

1. If you are making the change via the API, use the getMutationStatus endpoint to check when the change has been applied.
2. Add the header X-Coda-Doc-Version: latest to your requests, which will cause them to fail if there is a pending mutation. Keep retrying until the request succeeds.

If you want to dive a little deeper into why we have this delay, here is how the architecture is setup:

• Docs are composed of two things: a snapshot and a list of operations.
• When you make a change to the doc new operations are added to the list.
• When you load the doc in your browser, it starts by loading the snapshot, and then “replaying” the list of operations to catch it up to the latest state.
• The API backend can’t replay operations, so it’s just looking at the latest snapshot.
• New doc snapshots are taken on a regular basis, which for small docs can be within 30 seconds or so, but for larger more complex docs it may be every few minutes.

In rare occasions a doc can be stuck in a state where it never snapshots correctly, and so the API becomes wildly out of date. In these cases you can reach out to Support to see if they can help fix the doc.

[hector_p]

hi eric!

thanks for the prompt response!

man… that’s a bummer to hear.

thank’s for the reference to the getMutationStatus, i’ll have to check it out to see if i can implement it.

for the workarounds, do you see any reason not to use both simultaneously?

is there an api call to force a snapshot to be taken sooner, or any plans to allow this to take place (i can understand why it wouldn’t be allowed…but figured i’d ask )

it becomes enough out of date that it’s causing issues with the automated workflow i’m trying to implement with a piece of hardware on my c# wpf app. if those workarounds above don’t suffice, i may need to drop this effort altogether, unfortunately, as timing is precious on the production line.

[Eric_Koleda]

The problem with the X-Coda-Doc-Version: latest header is that it will fail the request if there is any pending mutation in the doc. For a busy doc with lots of users working on it at the same time the API requests may continue to fail for a long time. The getMutationStatus approach works better when you really only care about a specific mutation being completed.

There are no plans to change the situation in the near term, or allow for snapshots to be triggered manually.

The API and Coda are not designed to be a database for a live application, but are rather optimized for collaboration use cases. You may want to consider some more traditional database solutions (Xano, Supabase, etc) for your application data, using a Coda Pack to sync that data into a Coda doc for users to work with.

[hector_p]

thanks for the response!

ah, i see. so the getMutationStatus is for the specific mutation. got it - this makes more sense in this case.

would need to take a look at the alternatives at some point to see the feasibility. given time constraints, i’ve probably already spent (“wasted”) way too much time on this specific implementation in the eyes of the company, lol.

edit1:
@Eric_Koleda , i have a follow-up question regarding getMutationStatus, i’m getting an error statusCode 404 for “not found - no request with the given id was found”, but i’m using the correct requestId that gets responded to from the PostAsync function.

just for context, it was just working not too long ago.

thoughts on why/how that’s happening?

it’s not letting me upload an image for some reason.

here’s a link to the photo: Tuji-20250212-123517-7652 hosted at ImgBB — ImgBB

edit2:
i just tried again a moment agoand it’s all of a sudden working without changing anything… what’s going on.

[hector_p]

hey @Eric_Koleda, just pinging again, per coda support, in case you missed this reply. thank you!

[Eric_Koleda]

Hi @hector_p - I don’t get notified about edits, so safer to make a new reply if you want to get my attention.

There is unfortunately is a known issue with the getMutationStatus endpoint returning a 404, and this happens because of a replication delay in our backend. The solution is to add a short sleep, maybe a few seconds, before the first time you call that endpoint. That will give enough time for all of our backends to catch up and be aware of the new mutation ID.

[hector_p]

gotcha! will make a note to create a new reply for next time, thanks!

interesting… are you saying the following:

1. postasync()
2. read the response from the postasync() and extract the mutationid
3. wait a few seconds
4. then run the getasync() using the mutationid to the mutationStatus endpoint to get a proper response?

[hector_p]

hi @Eric_Koleda , just pinging again here to ensure my logic is correct. i’ve not yet been able to implement/test yet due to travelling.

[Eric_Koleda]

Hi @hector_p - Sorry for the delay, I was travelling too! Yes, your outline looks correct. Adding some time between creating the mutation and checking the status should remove the 404.

[hector_p]

no worries! thanks for the response.

ok, gotcha… thank you. sounds like this delay could definitely be problematic for me. i have to figure out a way to make it more speedy and use a less complex doc, or something.