The scenario you are describing happens quite often when first learning about Map/Reduce. I recommend checking out the webinars on Map/Reduce Views at www.couchbase.com/webinars so you understand it better. Also, understanding the Couchbase architecture itself can help as well, there are many presentations on this as well.
First, please make sure that the document doesn’t have an expiration that has expired already when querying your View! This happens quite often to people who are new. They set an expiration of 5 seconds, but then forget they did that, so they are removed from their View index by the time they query! Now, the Couchbase admin interface data explorer might still show it! because it is not intended to be updated as frequently as the production data/views nor compete with actual Views you author (meaning resources are limited for it). It can occasionally show stale data, instead it’s better to use GET operations to see data existence.
Ok, so if that’s not the case, let’s go into an explanation, the Indexers (Design Documents equate to Indexers), index documents in batches. The documents they index are the documents that are on disk therefore there can be a time gap between your ExecuteStore() and getting it on disk, if you query within that time gap and the Indexer hasn’t run, it won’t show in the result set.
What triggers the Indexer to index the new data that has been created or mutated?
There are three triggers: time, mutation count, and user initiated. You can configure the first two, and the default is 5 seconds, 5000 set/replace/add operations. User initiated is by using the stale=false or stale=update_after view query parameters. See: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-operation-autoupdate.html for configuration of defaults.
stale=false actually will wait for the Indexers to finish indexing new data since it’s last run before returning query results, which means there can be increased result latency. stale=update_after will first return the query results and then trigger the Indexer to run to update the Index with new data since the last run. stale=true basically will only return the current result set but not trigger the Indexers manually.
It is still possible to do an ExecuteStore(), immediately query the View with stale=false and still not see the result in the query results if the time gap between the ExecuteStore() and View Query is less than the time required to get the document on disk.
One technique would be to use the observe parameter on ExecuteStore() so that you get a callback when it has gotten on disk, and query the View after with stale=false. If that is not practical, you may need to think about using key-value patterns for immediate consistency if that is needed.