Open twilson63 opened 4 months ago
Note we need to add ability to init owner, so if I Spawn a process I can assign owner in boot loader
I believe the MU logic will have to change as well to call /result on the process id
Status: DRAFT
Currently at the ao
protocol unit level, evalutation does not occur on a process until the first Message
is sent. The first Message
triggers an eval on the cu
when the mu
calls the result endpoint.
As a result of this, users are forced to send a Message
to initialize their Process
with code and state after spawning. This is a cumbersome developer experience. A spawn
action should be a single step. To do this the protocol will handle an On-Boot
tag that defines a boot script either in the Data
field of the Process
, or as a transaction id.
The SU will generate an Assignment
DataItem
for a Process
when it is spawned. The Nonce
tag on the Assignment
will be the first index for the list of messages. So if the Process
Nonce
is 0, the first Message
Nonce
will start at 1. The Process
tag on the Assignment
will point to the Process
DataItem
. The Hash-Chain
tag will be seeded and set in the Process
Assignment
tags.
When the mu
receives a Process
DataItem
to spawn
it will send it to the su
and then call /result/processid
on the cu
, and continue pushing.
The cu
will handle a request to /result/processid
. It will load the Process
DataItem
and Assignment
from the su
and initiate a wasm evaluation with them.
The cu
will also treat the process as the first Message
in the stream for all new Processes
. Meaning for any new Process
the first Message
it retrieves from the su
Message
list will be the Process
. The cu
should handle this accordingly, but also continue to work for old Processes
where this is not the case.
When the su
receives a Process
DataItem
, it will generate an Assignment
with the above outlined specification. It will also make this Assignment
available on the /processes/processid
. It will also begin all Nonce
sequences at the Nonce
for the Process
as opposed to the first Message
. On the Message
list return that is available at /processid
the su should return this Process
and its Assignment
at Nonce
0.
When Spawning
a new Process
the user will now be able to spawn and initialize in 1 step. This will impact the internal logic of all 3 units, but mostly the SU and the CU.
The AOS process.lua
will need to be changed to enable evaluation of either the data
body, or the ability to read the provided tx via weavedrive to capture the lua code that needs to be evaluated. Then evaluate the lua code and return a result object.
All 3 unit types will be effected, as well as the specification for the Process
, which will now have an Assignment
aos(process.lua)
Process
and have the same Id
as the process, if this message has an On-Boot
tag and its value is data
then this handler should call the evaluate function passing the data for evaluation. if this message has an On-Boot
tag and its value is a txId
, then the handler will need to read the txId
from /data/{tx}
and capture that string and pass it to the evaluate function for evaluation. Since the handler is a once
handler it will remove itself from the list.Adding an Assignment
DataItem
to the Process
and modifying the behaviour of the units, will allow users to spawn and initialize in a single step.
Issue Summary: Boot Loader Implementation for AOS Process
Background
Currently, when spawning an AOS Process, the first item in the inbox is the Process Data Item, but evaluation does not occur until the first message is sent. We need to enable developers to initiate a boot loader that allows submitting data to be evaluated immediately when the client makes a GET {CU}/result/{pid} request. This request will evaluate the process, passing itself as the initial message to be evaluated and nothing else.
Problem
To act as a boot-loader, the CU must support the client's GET /result/{pid} request to trigger evaluation without receiving any other messages. This capability would allow the process to load Lua modules from a package manager or set up global states before receiving additional messages or cron jobs.
Solution Proposal
Update to
Process
DataItemSpec
if there is a new propertyOn-Boot
, the property can have a valuedata
or a TransactionId, if this is set, then the CU/Process needs to evaluate script code.or
There may be complications with Nonces; currently, the first message assigned by a SU receives a Nonce of
0
. If we cannot adjust the Nonce to treat the Process Data Item as the first (0
) message, we may need to set its nonce to-1
as the "pseudo-nonce" for the process.One potential approach (for any new processes) is to create an assignment data-item with a nonce of 0 and link it to the process, so the CU considers it the first message. This approach avoids the need to use
-1
as a nonce.The CU will then need to recognize when it is being asked to boot a process, as opposed to evaluating a message. This can be achieved by simply omitting the
process-id
query parameter typically passed to/result
when evaluating a message. If noprocess-id
is provided, then the CU will assume that the request is to boot a process and act accordingly.Affected Units
Action Items for Engineers
Evaluation Trigger on GET /result/{pid}:
Adjust Nonce Handling:
Boot Loader Capabilities:
Testing and Validation:
Feel free to reach out if there are any questions or further clarifications needed regarding this feature implementation.