Milestones returns empty list if accessed from a Feature that was accessed from a UserStory that had "Milestones" in its fetch params.

[bgreman]

PyRal 1.4.2 is what we're using but behavior is the same in 1.5.2

We're experiencing an issue like the following:

We query pyral for a UserStory by its formatted ID:

query_fetch = ['FormattedID', 'Name', 'c_MajorRelease', 'Owner', 'Project', 'ScheduleState', 'Feature', 'ObjectID', 'c_TestStrategy']
query_string = "FormattedID = {}".format(item_numeric_id)
results = self.rally.get('HierarchicalRequirement', project=project, fetch=query_fetch, query=query_string, projectScopeUp=True, projectScopeDown=True)

# assume we know we only get one result
story = results.next()
feature = story.Feature
milestones = feature.Milestones # this works correctly, milestones is appropriately populated

However, if we include Milestones in the fetch params, we get back an empty list for Milestones on the parent feature:

query_fetch = ['FormattedID', 'Name', 'c_MajorRelease', 'Owner', 'Project', 'ScheduleState', 'Feature', 'ObjectID', 'c_TestStrategy', 'Milestones']
query_string = "FormattedID = {}".format(item_numeric_id)
results = self.rally.get('HierarchicalRequirement', project=project, fetch=query_fetch, query=query_string, projectScopeUp=True, projectScopeDown=True)

# assume we know we only get one result
story = results.next()
feature = story.Feature
milestones = feature.Milestones # this returns an empty list

I would expect to get the correct list of Milestones back either way, as I am unsure why the query fetch params for the User Story would impact the retrieval of the Milestones for the Feature.

[klehman-rally]

I agree that the result is non-intuitive and that this is a defect. Thank you for providing code that displays the behavior, it certainly makes it easier for me to consider an issue when this is provided.

The short answer is that the pyral machinery for "chasing" attributes (especially reference attributes (aka _ref)) is doing what it was designed to do but the underlying Rally Web Services API (WSAPI) is inconsistent in the request response content.
I'd be happy to provide more detail if requested.

I also have a code fix for this but at present there is no schedule for publishing another release. At this point in the package's lifespan I usually try to collect a half dozen or so defects and/or features to justify a new release unless there are other compelling factors. As you've found a workaround and this being the first report in over a decade of the package's existence, I don't consider this defect as compelling. However, I can either post the fix code here in this issue or commit it to the master branch (sans published release). Let me know what can work for your situation.

[bgreman]

We're in no pressing need of an urgent fix, so your normal release cadence will be sufficient for us, I think.

On a personal level, I would be more curious about the details of the issue. And let me express my appreciation for your continued support and maintenance of this project. It's crucial to our in-house release management system.