multiple RHS that have longer-running fetches, I’d like the rules to trigger the ones it can and somehow wait for them/insert before finishing the session/firing.

maybe a low salience rule can wait/insert retrieved data?

Generally speaking, "Fetching" implies that data is being retrieved from external locations. External data generally implies stateful execution. Clara has trouble dealing with stateful RHS/LHS executions. As some/most of the core Truth Maintenance systems expect the LHS/RHS to be stateless. The bit that jumps out immediately would be logical retractions, expecting RHS to insert the same facts given the same inputs. If your RHSs are not stateless you run the risks of breaking the truth of the rulebase.

You are saying that for instance if the DB is queried twice then it might read two different values?

In that case I can just cache data for the session.

yes, if you RHS retrieved data for one execution of the RHS, given the same input clara expects that it will always return the same value.

I suppose either a low-salience rule that waits on outstanding threads would work? Or, maybe just multiple firings on the same session until there are no more active threads?

As a side note, clara makes no guarantees on how many times the RHS/LHS might be executed, only that in the end the session should be truthful. Your RHS might beat up your database.

so then the cache is more essential.

or couldn’t the LHS, just have in it “have i not fetched x”?

Going multi threaded is a little troublesome as introducing parallelism in the stored memory of clara might have undefined consequences. In the scenario where two interdependent facts are traversing the same join node... you'd have to have some global lock on node to avoid the "Facts passing in the night" without acknowledging each others presence.

Most patterns that i have encountered generally leaves the retrieval of data outside the scope of a session.

so then if i kick off threads in RHS, wait till after firing, check the threads/insert, then fire again/repeat would still fit that model of “retrieval of data” outside the scope of the session it sounds like. I could even just insert a fact that data needs to be retrieved and do all threading i suppose outside the session.

more in the sense that all external data is added to the session from calls like insert on the session directly

i suppose that in the fire-rules loop... you could have a "future-like" construct that would re-enqueue the pending updates in the session.... but that would likely only be at one activation grouping... likely spinning through all updates in a salience group then waiting on the futures within that salience group....

Yeah, I mean I was thinking it would be nice to get away from “spoon-feeding” facts to the rules and let the rules determine what facts are needed.

Jess has need-* rules that can be written that determine when facts are needed. I don’t know that it has thread support, but generally sounds useful.

the need-* supports backward chaining of rules, where one rule effectively goes in search of what it needs. Clara was written based on the Rete algorithm, focused on forward chaining. The spoon feeding in this case is a side effect of that forward chaining.