Bug is: The TreeNodes in the TreeStore aren't updated when a filter is removed, so the old state of the tree seems to be what is rendered. So workaround is thrash the store, get the loader to refresh the tree.
Thanks for this (and your other TreeStore post), I'm going to try to address each of the issues you've run into to make sure I understand them, or if they are usability ones, how we can make this easier to use.
For the asserts - we could make the error more noticable if you think it would help. We only want them to be asserts so that they don't run in production, as they are doing an otherwise unnecessary map lookup on every item that is added. This is meant to be a sanity check that the data makes sense, and that update shouldn't perhaps have been called instead.
For the other issue - do I understand correctly that this seems to boil down to just using replaceChildren with filters, and removing a filter? Store.removeFilters checks first that the filter was even present, then if filters are enabled. If it wasn't present, or filters were already disabled, there should be no need to apply the filters again. In your case, both should be true. TreeStore.applyFilters then checks again if filters are enabled, and if at least one filter is in the list, otherwise it just fires an event. Removing a filter (down to more than zero) then results in completely applying all filters again. On the other hand, removing filters down to zero means that items are not filtered at all any more. This seems to be the most likely case for your bug.
All TreeStore.TreeModel operations should check if a) the filters are enabled, and b) if there are any filters, in the same way as applyFilters does, and if both are false, it should return only the full set of children. We have a handful of unit tests covering these cases, but from your bug we seem to be missing at least one case, or perhaps your filter is changing in a way we don't support or didn't anticipate.
To help solve that one way or another, can you post a simple Entrypoint that demonstrates this issue, or at least a series of steps to reproduce this (like 1. add filter, 2. use replaceChildren/replaceSubTree to add items, some visible, some not?, 3. remove original filter). My very brief initial testing hasn't demonstrated the issue yet.
This bug has been fixed in the Ext GWT 3.0 Release Candidate. Please upgrade your copy of Ext GWT and try your test case again. While we're confident that we've addressed this issue, please reply if you notice any continued problems after upgrading. Again, thanks for taking the time to report this bug.