Obtaining fiber uris

1. Automate Community
2. Tutorials & Examples

As an answer to HS's flow on this subject:
https://llamalab.com/automate/community/flows/44483

This is needed since subroutine blocks don't have a Uri variable output as forks do, but you may need them (e.g. give/take vars). So until (if) this be added as a feature, this is a way to do it that uses few blocks, by using the AM SQL that can be queried.
If you query content://com.llamalab.automate.provider/flows/xxx/fibers you get info over every fiber of that flow. Every fiber has a dictionary with:
_id = its own id as a running fiber, once it's stopped this id is useless.
flow_id = the id of the flow to which it pertains (i.e. the xxx in the Uri above)
statement_id = is the id of the block where at the moment of the query the fiber was running
started_at = is the id of the block AFTER the beginning/fork/sub where this fiber started, so NOT the beginning/fork/sub itself
parent_id = id of the fiber that started this fiber (null in case it is the beginning, obviously)
return_to = only for subroutines, the id of the sub block that started this

For our purposes here we are only interested in _id (obviously), statement_id and started_at. In a simple flow without many concurrent fibers you may even have enough with just the started_at or just getting the last item in the array of fibers. But if you have many fibers (forks and subs) or especially subs that reiterate (call itself), it could get more difficult. If there start many fibers at same time then using just the last item is insufficient. When you use the same sub or fork the block id is the same, so the strated_at will be the same as older fibers.
So if you have a sub with block id 10, and immediately after you place your query block (say it's id 11), you should put as where clause "started_at = 11". If there are other blocks before the query and after the sub, the id should be of the first block that comes after the sub. If your sub reiterates over itself, you will have to query additionally for "statement_id = 11" or whatever id the query block is (if it's not the first after the sub block you will be looking for two different numbers). This will get you the current iteration's fiber id. The older iterations will be currently at a different block so they will not turn up. If you were interested in the older ones, that's how you can get them.
You could also use this to query for id's of other fibers that otherwise would take atomic or give/take var blocks to get, and so use more blocks than this solution. Immagine you have a fork within a fork, so the only other way to get the child fiber uri output from that block to another fiber is through atomic or give/take var. But if you use the started_at query you could find that fiber with just one block.
The obvious downside to this is, whenever you change the blocks you may have to adapt the query, and if you don't...
Hope this is clear else leave comments. Hope it helps and works for you. Any further ideas or questions all in the comments!