Shopify Flow app Get fulfillment order data (fulfillmentOrders) query mystique - it don't work right

[ConundrumHouse]

I need a flow that sends emails to customers currently in open stage of order fulfillment. But not all such, only those that have purchased a certain product variant - of which there are a few. 

I ran into trouble running queries on the Advanced edit query panel - while it looks like I can put in selectors on any of the fields like tags on the order or customer, the query fails to select and returns all orders in fulfillment. I can narrow it to just open ones, but that still more than I am targeting.

OK, so I did some digging, it seems that only a rare few fields can be utilized in that query - list is not published, it seems. But id: works, but orderId: doesn't. Though the schema implies both are nodes at the same level.

So request #1 - where is documented what can be queried at the top level of this request? And the other types like this?

Alright - so now I have a collection of records that contains more than I need, and I can iterate over the set and do further matching on each record to select orders/customers to do more with. I can send an email. And I want to tag the order so next time the flow runs, I can avoid this customer, and find the new ones. But I can NOT sequence another action after the action customer email is sent - I have to do a selection iteration AGAIN to set tags.

So request #2 - what am I missing, as this severely obscures the logic, layout  and efficiency of the flow. Is it just a feature not implemented to chain actions for matching items in a For Each... action?

Further observations - 

During the extended experimenting to see what is going on with this query selection mystique, I find that while the record reports 

"node": {
"id": "gid://shopify/FulfillmentOrder/7025209737409",
"orderId": "gid://shopify/Order/6099500269761",
"orderName": "#3926"

}

for one of the matching results, and if I specify a query

 fulfillmentOrders( first: 20 query: "id:7025209737409 OR id:6967990485185" ) 

it finds those records, and returns only two.

But if I search for "gid://shopify/FulfillmentOrder/7025209737409" it doesn't find it. (I suspect the record holds just the GID, and it is pretty printed for the GUI with context.)

Further, according to the Doc, if I do something like "id:70*" it should be doing a partial string match, which it doesn't do - again, probably a feature of the DB itself that treat GID's as pure objects for which partial matches is meaningless.
Also, the query syntax docs say that just giving a name or string will match for anything in the record. Nuh-ah. It won't match a GID against such a string, it seems. So the string search for matches in queries, at least for this fulfillmentOrders request is inoperative.

And to drive this home - the result fragment shown above shows both the "id" "orderId" and "orderName" at the top level in the node returned, but only the id is searchable/selectable in the query. If I try to select on orderName ONLY I get a 

"warnings": [
{
"field": "orderName",
"message": "Invalid search field for this query."
}

but if I OR that with valid id: terms it finds the two (in my test case) but does not warn about the orderName term. Again, probably due to lazy eval - if an OR term fails it doesn't need to impact the result, but if the failing term is the only term, it propagates back as a warning/error.

Oh, and also, if I try to use orderId:, which is a GID, it also fails like orderName. I thought just perhaps some interior fields are more special than other, but alas, no.

So I think I have a clunky, very spaghetti-like flow that repeats the same iteration over the returned set to filter out what I could specify and select for in the query in the first place.

But I would love for #1 to be resolved at the query level, and  #2 for the chaining of actions after iterations so I don't have to replicate such.

Thanks for reading this. I can show specific screen shots or code snaps if more info is needed.

|\\/|ark

[paul_n]

To find the filters available: 

For the #2 issue, when this was released we had in infrastructure limitation that prevented us from running potentially 100 loop iterations plus 2 or more actions in those loops (for 200+ potential actions). We are working to remove this specific limit, but short term, you could get 50 at a time and loop twice. 

For the fulfillmentOrder issue, I'm not following your description. But query filters typically take just the number part of the ID and NOT the full GID string. That's how the API works, not a Flow thing.