We have some content, and some of the items can be seen by one group of users, some of them by another group of users.  Using visitor groups, we are able to get these to appear correctly in various cases, and we use FilterForDisplay to ensure users only see the right values.  This works in almost all cases, including when browsing the website and while in the cms admin area using the personalization dropdown.  However, in one case we make a call out to a web service to retrieve additional data.  In order to be performant, we do this using async/await (we are using MVC).  So it looks something like this:

// pseudocode...

// gets group name from web service call...
string groupName = await GetUserGroupName();

// in the criterion, this overrides the user's actual group if present...
Session.Add("EffectiveGroup", groupName);

// get items from content loader....
var items = contentLoader.GetChildren(ContentLink, LanguageSelector.AutoDetect(true));

// filter the items appropriate for the effective group...
items = items.FilterForDisplay(true, false);

Now, here's the meat of the issue:

When the above runs, the items do not get filtered correctly.  Only items that are visible to everyone come back.  Items that require a groupName are omitted.

That might lead me to believe my visitor group criteria was wrong, but here's the weird part: if instead of calling await, I hard code the groupName, then the items *are* filtered correctly.  We have tested thoroughly, and if the result of the GetUserGroupName() is "Blue" then hard coding "Blue" causes the above to work, but as soon as await is used, it breaks, despite groupName being the same in either case, and both going through the session, etc.

So I'm wondering whether anyone has had luck using FilterForDisplay after an async method has returned, or whether anyone can think of a reason that it might fail.  By default, aspnet should preserve the session and whatnot across the await call (we are targeting 4.5.1), so it seems like this should be safe.  Even beyond that, we only touch the session after the call has returned, not during the task execution or before run.  I am wondering if EpiServer does something when beginning a request that doesn't get performed when the request resumes (possibly in another thread) after the await resumes.  e.g. it has some thread local state or something that might cause visitor groups and/or filtering not to work at that point?

Anyway, just a handful of thoughts.  If anyone has any insight that might help illuminate the issue, I'd be grateful.