From a persisted function’s perspective, there are two sources of data: its own and that which gets submitted from the outside. the function is entirely responsible for the shape of its own data. it can add timestamps to it if it wants but they’re not there by default since there is no default. all of the data coming in from the outside is the result of a “system call” which the persisted function had previously made, but beyond being associated with that system call, there is no metadata associated with it. one such system call you can make is to ask for the current time. we try to do as little as possible in the runtime. anything which can be offered using software inside the system, should be. what you’re describing could be a library. though i suspect that i don’t exactly get what you’re saying with fresh vs stale. my first thought is that if you’re concerned with this, you should ask your data sources to tag their data with time or sequence numbers, or do so yourself at insertion. but the data that we insert might not come from the outside, we could for example discard the input and update our state by simply incrementing it by one, or something. should the new state have the same timestamp as the input, or as the previous state?

Replies (1)

Doing as little as possible in the runtime makes a lot of sense. Less overhead, less to maintain, etc. As for the freshness, I was originally thinking perhaps latency sensitive function calls might pose a problem if the process crashes and recovers seconds later and responds with data that’s no longer relevant. Given these are pure functions it makes total sense to just pass along the timestamp (or increment a counter) and these considerations are going to be app dependent anyway. I’m really excited about this project and plan to experiment with it in the near future. The docs are well written too. Thank you for the work and the thoughtful response!