Bug during conflict resoultions: view doesn't update

I have a mobile android app with couchbaselite 1.2.0. The app db is in pull (just pull) replication with a sync gateway.
Any time i modify an app’s document i put a special property in it so that when i have conflicts due to pull replication, i’m able to identify the mobile revision and create a tombstone because by design, i want mobile app changes overriden by the server version.

When such a conflict happens, my view index is not rebuild (mapper is not invoked) and the document, which previuosly was correctly shown by the query, doesn’t show anymore as if it was deleted, but it wasn’t as the server revision becomes the current revision (i’ve checked this and it works correctly).

The only way i found to force view rebuild so i have a correct query functionality is to perform a setMap with null mapper before resetting the right mapper

view.setMap(null, "6");
view.setMap(new Mapper() {
            public void map(Map<String, Object> document, Emitter emitter) {

                if (document.get("virtual") != null && !(Boolean)document.get("virtual")  {
                    emitter.emit(document.get("floor"), document.get("_id"));

        }, "5");

this works and rebuild the index any time i perform a query. I know it is inefficient but at least it works.

As a side note, if i use a db.createAllDocumentsQuery() i don’t face the problem as that kind of special query works correctly.

The following snippet is an extract of the code i use to create tombstone:

for (SavedRevision savedRevision : conflictingRevisions) {

	if (savedRevision.getProperties().containsKey(MOBILE_MOD_KEY)) {
		L.i("removing version " + savedRevision.getId() + " because it is a mobile modification");
		UnsavedRevision unsavedRevision = savedRevision.createRevision();


The above snippet correctly promotes the server revision (the other one in the conflicts) as the current revision. The snippet is invoked during

database.addChangeListener(new Database.ChangeListener() {
                public void changed(Database.ChangeEvent event) {

I think this is a bug as in all other cases it works well.
Can you tell me if it is something known that was fixed in 1.2.1? Can you tell me if there is any drawback to view.setMap(null, "6"); code?

Thanks in advance