Gotcha. So, from the user/editor’s perspective, and they’re editing a single line text field, this is when they click away from the cell?
I think it is an issue of not knowing when the user is done typing. It is possible for Airtable to fully commit text changes, but how can Airtable know when a user is really done typing?
Airtable can know when the focus leaves the control, at which point the user is probably done typing. But sometimes I’m still typing in a text box and I change the focus because I want to momentarily put my attention somewhere else, even though I’m not done typing.
Yes, but there are many aspects to the event handler that triggers based on certain conditions.
I think the enterprise webhooks do know when to fire the “done typing” events. Certainly with greater precision than a formula could measure.
This would cause the event handler to fire two times. But that’s a common aspect of programming with any webhook system. You must create webhook listeners that act favorably to such occurrences.
But that’s my point. The event handler saying that text has changed fires for each “chunk” of text, but the “chunks” don’t really correspond to when the user is done typing.
For example, automations that check for the presence of text in a field fire as soon as the user starts typing. This is because that first character or first few characters are already committed. When people type slowly, the automation triggers with only the first character, but if someone types fast, the automation might contain multiple characters. If someone triggers the automation for when the field changes, it will fire multiple times before the user stops actually typing for real.
Have you used enterprise webhooks? Or, are you speaking purely about the trigger behaviors in Airtable itself?
No. But I have read the documentation and nothing I’ve read implies that enterprise webhooks can know when a user is done typing based on my idea of when a user is done typing. (Which might be different from your idea of when a user is done typing. My idea of when a user is done typing is highly colored by the idea of a parent working from home who gets interrupted mid-sentence by a child.)
I am thinking that knowing when a human is done typing is an incredibly difficult task. There are proxies like when the focus moves from a control or when a certain amount of time passes without additional input. But while these may be good enough for most cases, they are not guarantees that the user is actually done typing.
Plus the idea of using enterprise webhooks for Julian’s use case seems extreme. In order to use enterprise webhooks you have to set up a system to receive the webhook, register the webhook, manage refresh tokens, go back and ask for the payload, and so much more. Not to mention being limited to only ten webhooks per base, and two webhooks per connection. Way too much work to send a slack notification.
I recommend a few tests to compare how each performs. My experience is that enterprise webhooks possess some magic that does not exist in other event handlers of the Airtable platform.
Events are notoriously ambiguous about the conditions that trigger them. I get the sense that Airtable Proper is weak, and Airtable Enterprise is an industrial version of the weak stuff made available to all paying customers.
Ambiguity in webhooks will always be there, so developers building truly real-time systems must also craft a deep sensitivity to webhook events that maybe should be ignored.
A good example is the Copper CRM system. It generates webhooks concerning object changes without deference to field completion. I overcame this in one project by using AI embeddings to test if the data was likely complete. Embeddings, as you know, are blistering fast vectors that can definitively tell you if the data is similar to a learner shot. If not, the score is low, and the event should be rejected from further automation processing. This is just one example of mitigating poorly-designed outbound event webhook systems.
This is both really cool that a more robust version exists, and sad that it is gated to enterprise.
Agree. This aspect of the APIs should be common to their entire offering. So few working in Airtable Proper will utilize this that it will have little impact on the service. In fact, it would probably free up resources and this policy demonstrates why Airtable is out of touch with their customer base.
One of my Top 20 Biggest Shocks™️ when switching from being a Certified FileMaker Developer to an Airtable Consultant was that Airtable didn’t natively understand the concept of “committing records”. This concept is built into every single layer of the entire FileMaker platform, and can be programmatically controlled as well.
1 Like
The commit concept is a fundamental tenet of transactional processing. Without it, you have no ability to roll back transactions in the event of dependency update failures. This leads to fractured relationships, orphaned children, etc.
But it’s a rare case that any no-code enthusiasts would need to know if changes are actually committed, or to care much about the tenuous nature of transactional processing. However, suddenly no-coders care as soon as they are handed a new construct - automations based on record changes. Now they care about “commits” without actually knowing why. So they throw other crap (like NOW()) at the problem, and this makes it worse.
I believe the Enterprise events API was developed many years after the other APIs and may contain a better notion of optimistic committed changes. Perhaps there is an element of pessimistic commits baked into the algorithm.
2 Likes
I understand that transactions as complete units are important.
I still don’t see how the concept of a commit relates to knowing when a user is done typing. Knowing when a user is done is such a tricky matter. For example, when typing a reply on this forum, I may put down and pick up my phone multiple times. I switch to different tabs in my browser. But the forum still needs me to press a button to say when I am done typing.
I am totally willling to believe that the enterprise events api does a better job of grouping typing sessions than automations. The record history log seems to do a decent job of deciding which characters were changed together, but that predates the enterprise events api, and sometimes groups changes in ways that hide conditions that could trigger automations.
Similar to what @kuovonne mentioned above, in FileMaker, the user would indicate that they are done typing by clicking anywhere on the screen that is OUTSIDE of the field. The click of the mouse indicated a commit. So it did require manual user intervention. (However, the commits could also be controlled programmatically by the developer as well, because we could monitor users’ keystrokes and other behaviors.)
1 Like
Precisely. There is no such corollary action in Airtable. As such, it (a) assumes everything is saved as you change fields, and (b) must use an optimistic commit assertion.
Similar constructs exist with regard to record locking.
Huh? Airtable saves changes before you change fields. I can be typing along in a field with my cursor staying in that field, and formulas recalculate, automations trigger, and other users on other computers see what I have typed. Those changes have to be saved before I change fields in order for all those things happen.
I think we’re saying the same thing. There is no “save” button for changes to Airtable fields, right?
Correct (except for forms). But I though you said that Airtable saves as you change fields, and I think it saves as you type. Not necessarily with every key press (although it may seem that way), but also well before the human thinks typing is complete.
And the API, and scripts (I think).
Perhaps, but that’s irrelevant. It uses an internal mechanism that ambiguates the definition of a commit. And with that, triggers in automations are equally ambiguous. One might conclude that commits are optimistic - i.e., they have a wide range of possibilities in the no-code features.
I believe Enterprise events (as interpreted by the Enterprise API) lean toward pessimistic commit behaviors. As such, anyone trying to build precise automations may have far better luck creating webhooks to sense data modifications.
I have created outbound webhooks that have worked really well. This is why I believe the event handlers used by the Enterprise API are not the same event handlers implemented in the no-code client.
Based on this user’s problem with Airtable’s Enterprise webhooks, it doesn’t seem like the behavior is any different with Airtable’s webhooks:
This post in the Khoros community is from someone who has not read the documentation.
Developers who are unaccustomed to the basic premise of a webhook need to know that the hook is designed to be a notification of the change, not the actual changed value.
When a change that matches the webhook’s specification occurs, we send a notification via a POST request to the relevant webhook’s notification URL containing the base ID and the webhook ID.
The client (your webhook listener) is obligated to intelligently unpack the notification payload and use it (and following notifications) to understand the nature of the change.
The recipient of this request should respond with an HTTP 200 or 204 status code and an empty response body. After successful delivery, the recipient of this notification is then responsible for requesting the contents of the updates from the API (using list webhook payloads) in a separate HTTP request.
I could be wrong, but I don’t get the sense that this user is doing this. I think he’s assuming a webhook POST is a one-and-done proposition.
Well, it is different because, unlike the events in the client, the Enterprise API sends all sorts of information useful to understanding the likelihood that a field edit has been completed. As a developer, it’s your duty to build a listener that takes advantage of this added stream of data.