This PR isn't ready. I haven't run the code yet. Just wanted to push it for an opinion.
After realizing that matrix transaction IDs are just supposed to be unique across a single auth token, I changed the approach away from the one I mentioned in #1.
Now a bot's State map contains a txn_id field. You can look at the message case for the {get_txn_id,Caller} message in tuvix:loop to see how it is meant to work.
The idea is that, if an action handler wants to send an event to a room, it needs to first request a new transaction ID from the bot using a synchronous function tuvix:request_txn_id, and then it proceeds to make whatever request it needs to make.
This PR isn't ready. I haven't run the code yet. Just wanted to push it for an opinion.
After realizing that matrix transaction IDs are just supposed to be unique across a single auth token, I changed the approach away from the one I mentioned in #1.
Now a bot's
Statemap contains atxn_idfield. You can look at the message case for the{get_txn_id,Caller}message intuvix:loopto see how it is meant to work.The idea is that, if an action handler wants to send an event to a room, it needs to first request a new transaction ID from the bot using a synchronous function
tuvix:request_txn_id, and then it proceeds to make whatever request it needs to make.