WorkflowRunsOperations.list arguments top and filter not working?

[c4g-wv]

Dear,

I'm trying to use the list method of the WorkflowRunsOperations, but when I specify top=5 for example, I still seem to be getting all runs. It's as if the top argument is not taken into account?
Additionally, I'm trying to use the filter on StartTime, but keeps giving a "not valid or not supported" error. Things I've tried so far:

• filter="StartTime>2021-11-23 00:00:00"
• filter="StartTime>2021-11-23Z00:00:00"
• filter="StartTime>'2021-11-23Z00:00:00'"
• filter="StartTime>'2021-11-23'"
• filter="StartTime>2021-11-23"

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8321b046-0079-e62b-2006-b0c58b90eadf
• Version Independent ID: 62407551-e186-893d-8143-5b4aad731031
• Content: azure.mgmt.logic.operations.WorkflowRunsOperations class
• Content Source: docs-ref-autogen/azure-mgmt-logic/azure.mgmt.logic.operations.WorkflowRunsOperations.yml
• GitHub Login: @lmazuel
• Microsoft Alias: lmazuel

[c4g-wv]

For the "filter" argument, the right syntax seems to be:
StartTime gt 2021-11-23T00:00:00Z
Might be good to add to docmentation.

For the "top" argument, still not picking up the integer value, also tried passing it as string.

[YalinLi0312]

@c4g-wv Thanks for your feedback, we'll investigate asap.

[SaurabhSharma-MSFT]

@c4g-wv Would you mind providing the code snippet you are using to get the results ?

[c4g-wv]

@SaurabhSharma-MSFT test code could look something like this:

logicClient = LogicManagementClient(DefaultAzureCredential(), *sanitized subscr id*)
it = logicClient.workflow_runs.list(*sanitized rg name*,*logic app name*,top=1)
for i in it:
	print(i)

fyi: tested it on python 3.8 and 3.9

[SaurabhSharma-MSFT]

@c4g-wv I have tested this in my environment and you are correct filter works with the time format - 2021-11-23T00:00:00Z.

Also, I have also tried with using top but it does not work for me either.
Though I have tested the Workflow-Runs rest API and it worked fine with REST endpoint.
https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Logic/workflows/{{workflowName}}/runs?api-version=2016-06-01&$filter=StartTime ge 2021-11-23T00:00:00Z&$top=2

I am checking internally on the same and get back to you.

Thanks
Saurabh

[PramodValavala-MSFT]

@c4g-wv the list method here returns an object of type AsyncItemPaged which basically iterates through all the pages until there are none. The top parameter is actually working here but you end looping through pages of 5 entries. Either you could use a regular for loop and it.next() the fixed number of times like this

logicClient = LogicManagementClient(DefaultAzureCredential(), "sub-id")
it = logicClient.workflow_runs.list("rg-name", "la-name", top = 5)
for i in range(0, 5):
    curr = it.next()
    print(curr)

Or just loop through the first page like this

logicClient = LogicManagementClient(DefaultAzureCredential(), "sub-id")
pages = logicClient.workflow_runs.list("rg-name", "la-name", top = 5).by_page()
for i in pages.next():
    print(i)

[c4g-wv]

@PramodValavala-MSFT : thanks for looking into it. I agree, there are workarounds, but it's not how I expect it to work. Through REST API, it is properly giving 1 result back. Also, the "filter" argument is giving a proper reduced list (both in REST API and logicClient.workflow_runs.list function), so I'm not quite clear why it would have to be different for the "top" argument.

[PramodValavala-MSFT]

@c4g-wv You are right. In fact, the first response does return just five results, but the problem seems to be that the service returns a nextLink which the SDK uses to fetch consequent pages when iterating. AFAIK it should not be set when using top but either way, I will share this feedback with the concerning team and get back to you.

[SaurabhSharma-MSFT]

@c4g-wv Please let us know if you have any additional questions else we will proceed with the closure of this issue.

[c4g-wv]

@SaurabhSharma-MSFT : Personally, I don't consider the issue closed. There is a workaround, I agree, but the parameter does not behave the way it's supposed to behave. Though, if the development team has decided not to fix it, then you can go ahead with closure.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/azure-logicapps-team.

Issue Details

---

Dear,

I'm trying to use the list method of the WorkflowRunsOperations, but when I specify top=5 for example, I still seem to be getting all runs. It's as if the top argument is not taken into account?
Additionally, I'm trying to use the filter on StartTime, but keeps giving a "not valid or not supported" error. Things I've tried so far:

• filter="StartTime>2021-11-23 00:00:00"
• filter="StartTime>2021-11-23Z00:00:00"
• filter="StartTime>'2021-11-23Z00:00:00'"
• filter="StartTime>'2021-11-23'"
• filter="StartTime>2021-11-23"

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8321b046-0079-e62b-2006-b0c58b90eadf
• Version Independent ID: 62407551-e186-893d-8143-5b4aad731031
• Content: azure.mgmt.logic.operations.WorkflowRunsOperations class
• Content Source: docs-ref-autogen/azure-mgmt-logic/azure.mgmt.logic.operations.WorkflowRunsOperations.yml
• GitHub Login: @lmazuel
• Microsoft Alias: lmazuel

Author:	c4g-wv
Assignees:	SaurabhSharma-MSFT, PramodValavala-MSFT, msyyc
Labels:	question, Logic App, Service Attention, Mgmt, customer-reported, needs-team-attention, CXP Attention
Milestone:	-

[xiangyan99]

Given the linked PR was closed as completed. I will close this one. Please feel free to reopen it if it is not solved.

[ghost]

Hi @c4g-wv. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @c4g-wv, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.