How JarvisCore agents find each other without an orchestrator
by•
JarvisCore agents join a peer-to-peer mesh. They find each other through gossip and message agent to agent, with no orchestrator or broker in between. The same code runs in one process or across machines.
You're welcome to try it out.
For more reads: https://jarviscore.developers.prescottdata.io/concepts/p2p/
71 views
Replies
When a request times out can the caller check whether the peer finished the work before retrying?
A lost reply after a successful write seems like an important case to show in the examples
@al_kub
Great question, Aleksandr, and you're right that this case should be in the examples.
Short answer: it depends on how you send the work.
As a workflow step: yes, you can check.
The peer claims the step in Redis, runs it, and records its status and output there. The caller reads the result from Redis instead of waiting on the reply, so a lost reply doesn't lose the work, and a completed step won't run twice.
As a direct peers.request(): not yet.
A timeout only tells you that no reply came back, and each retry goes out as a new request. Today you handle this with an idempotency key: the caller sends a key with the request and reuses it on every retry, and the peer stores the result for each key. A retry after a lost reply then gets the first result back instead of doing the write again. Keep those keys in Redis and claim each one atomically, so it survives restarts and a retry that arrives mid-write can't run the work twice.
I'm adding a runnable example of both cases to the docs and will share the link here once it's in. Thanks for raising it!
@al_kub Following up: the example is now in the docs.
Retries and lost replies: https://jarviscore.developers.prescottdata.io/concepts/p2p/#retries-and-lost-replies
Runnable example: https://github.com/Prescott-Data/jarviscore-framework/blob/main/examples/p2p_lost_reply_retry.py
It runs three cases without an LLM key or Redis:
A retry without an idempotency key charges the card twice.
A retry with an idempotency key returns the original charge result.
A retry that arrives while the first charge is still running waits for it.