I followed steps listed here but didn't get your same outcome. Can you clarify the steps to reproduce, the expected result, and the version of Phabricator you're using.

Does the task go away from the workboard when you refresh? I think that's the missing step here, that you're editing the task on the workboard.

Thanks for looking @chad

Version: 8b56e0082bff4807ea1ea275741d5f145804e0ee

Repro steps (with a bit more detail):

• (1) Create a Milestone (e.g., "Sprint 1") on a Project
• (2) Add A Task (e.g., "Do X") to that Milestone
• (3) Edit the tags on that Task, adding the top-level Project tag
• (4) Go to the top-level Project workboard, notice that the task is still in the Milestone column
• (3) Go to the Milestone workboard, notice that the task is no longer in Milestone

Expected result:
After step (3), I would expect that the Task would

• Appear in the Default column of the top-level Project (this is not happening as expected)
• No longer appear on the Milestone Project (this is happening as expected)

T10486 is related; T6027 and T5214 are somewhat related.

Partly, I'm not sure all users would share your expectation in the general case. That is, if I'm on Workboard A, and create a task and set the tags to "B", I think some users would expect it to still be on "A" (like: "I just meant to add B, I removed A by accident but I'm on the A workboard so obviously the task should be created onto the workboard").

The case where you replace A with some superproject or subproject of A (as here) is less murky.

I think it's possible that we should do something like lock "A" into the field and prevent it from being removed.

T10349 also discusses the "Edit" case of this:

Workboard Updates after Edits: Certain updates to workboards (like manually changing which milestone project a task is in) are not properly reflected in the client-side UI. This will work properly after additional work in pursuit of real-time workboard updates (see T4900). This may get fixed before that. In the meantime, a workaround is to reload the page after making these edits. I expect these edits to be rare.

That case is narrower (UI inconsistency only, no data inconsistency) but similar.

Hmm... maybe I'm not explaining my expectation well, but the "issue" I'm referring to is the fact that after steps (1)-(3) I now have a task that is in the "Subproject A" column in my "Project X" workboard but is not *actually* in Subproject A anymore.

For example, here's the Sprint 2 workboard column on Project "Subscriptions::

And here's Sprint 2's full workboard:

This is now inconsistent. "Test 2" appears to be in "Sprint 2" if I'm looking at the full project view, but is not actually in "Sprint 2"

Yeah -- it's not very clear on its own, but this comment is specifically referring to that issue:

T10486#162996

There's just a big cloud of adjacent issues which almost certainly make sense to resolve at the same time since they're in the affected code, and not all of them have straightforward product outcomes.