Watches are only supported on individual keys, not on ranges. If you want to track changes to a range, one way is to have a separate key that you modify every time the range gets modified. This key could store a value that’s incremented with atomic adds or that includes a versionstamp. Then you could watch this key to know when the range is updated. There’s a good bit of discussion about this in this thread.
The contract is a little different than this. Instead of the first change, you’ll be notified when the key has changed, assuming it stays changed. It’s possible the key may have undergone multiple changes by the time you are notified, and it’s also possible in the case of an ABA update (one where the value changes from A to B and then back to A) that you may not be notified at all. If you use atomic add or versionstamps as I described above, though, then you don’t have to worry about the ABA problem.
In order to be notified about future changes after a watch fires, you’ll want to set a new watch in the same transaction as the one where you read the range of keys being watched.
The transaction that creates a watch needs to be committed in order for the watch to be set. A watch that isn’t committed can only be triggered by modifications that happen in the same transaction as the watch. Is your watch transaction being committed?