# Watch semantics

**URL:** <https://forums.foundationdb.org/t/watch-semantics/1480>\
**Category:** Using FoundationDB\
**Created:** [June 23, 2019, 12:08am UTC](https://forums.foundationdb.org/t/watch-semantics/1480 "2019-06-23T00:08:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrew.noyes](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/andrew.noyes/32/443_2.png) [@andrew.noyes](https://forums.foundationdb.org/u/andrew.noyes)\
**Post date:** [June 23, 2019, 12:08am UTC](https://forums.foundationdb.org/t/watch-semantics/1480/1 "2019-06-23T00:08:14Z")

</div>

I looked through the simulation tests and I can’t find anything that waits on a watch future outside of a retry loop. The [documentation](https://apple.github.io/foundationdb/developer-guide.html#watches) gives an example of waiting on a watch future outside of a retry loop. It seems that it’s possible that a watch future errors with `future_version` if the storage node gets partitioned from the cluster but not the client for example (see [this])([https://github.com/apple/foundationdb/blob/df0baa00662a9a048befb633d91722024ec05df3/fdbserver/storageserver.actor.cpp#L815](https://github.com/apple/foundationdb/blob/df0baa00662a9a048befb633d91722024ec05df3/fdbserver/storageserver.actor.cpp#L815))

What behavior can a user expect here? I think we should either

1. Document the possible errors for a watch future  
or
2. Transparently retry the watch within the client and have simulation tests that wait on watch futures outside of retry loops