croncats / contracts Goto Github PK

Allow a task owner to refill (add NEAR) to their task, so it can continue operating without having the task run out.

UI: See attached screenshots, there are 3 pieces to this:

1. Create a new "Refill" button next to the clone button, color it orange. It will only show on a task that logged in user matches task owner_id, see "Delete" button. Clicking Refill will launch the new refill task modal (needs to be created as part of this ticket)
2. Create new modal, to be launched from the tasks page, accepting parameters for a task. See UI, it is a simple input (that can be taken from create task page), will need to generate a signed transaction that goes through near wallet. Method for refill is "contract.refill_balance(task_hash)" Source, you can do something similar to create task method here
3. Show the success results for the task being refilled & allow user to close modal

Refill button

Refill Modal

Refill Success

Based on current agent status changes, an agent could register, become pending, then go offline.
If there is a tiny function that can be called upon allowing agent to become active, it would confirm the agent was offline. This function would have a timeout, and allow active agents to kick from pending pool allowing the next pending agent an opportunity to become active.

Requirements:

• get from pending to active function, agent has to change its own status once its approved
• VecDeque for agents, so we adopt pending correctly

NOTE:S

• remove DEBUG
• CryptoHash (nearcore) for Vec hashes
• simplify timestamps to milliseconds
• get task methods -- add task hash where possible
• add param for recurring until failure
• add docs about gas restriction and it will be charged full amount regardless

https://github.com/near/sandbox

Tests

• new
• migrate
• tick
• create task
  • cant add during paused
  • cadence
  • total deposit can cover at least 1
  • recurring has enough balance for 2
  • gas doesnt exceed max or min
  • get hash that matches expectations
  • gets added to right slot
• proxy call
  • cant call during paused
  • must be registered agent
  • no tasks
  • tasks available
  • not enough balance
  • enough balance
  • Next slot scheduled
• update task
• stop/cancel task
• get tasks
• hash
• get agent
• register agent (TEST)
• update agent (TEST)
• unregister agent (TEST)
• withdraw (TEST)

Goals for fair agent processing:

• keep track of active agents
• keep track of pending agents
• when agent checks if tasks are available, return only tasks they are allowed to execute (count)
• add configuration for DAO controlled agent to tasks ratio
• create a cron task to onboard new agent when task threshold exceeds new ratio
• setup a "sweeper" agent(s) that occurs when agent misses a task they were supposed to call (tasks in a floor_key)

Floorkey issue - see: near view manager_v1.cron.testnet get_slot_ids

• Change storage keys to enums
• Add admin fns to manage settings
• paused to fns
• Add asserts to check cadence can be parsed
• Change OOP, be careful on rewind execution!
• How can this promise execute and allow panics?
• Adjust this to get slot from treemap floor?
• update state, post pop
• Process task exit, if no future task can execute
• Change to real gas used
• assert that attached deposit is enough to cover storage cost. This is to protect from storage attack.

Happens when:

• no agents
• agent starts after scheduled slot

Setup PRs for all the accounts to move to croncat.testnet

See: https://learn.figment.io/network-documentation/near/tutorials/1-project_overview/5-account-storage

Requirements:

• Implement the standards for cron agents -- see Agent struct
• extend/change Agent struct such that we can tally storage balance & rewards for an agent.
• update unregister method and tests to support storage exit

General:

Empty Slot

• TBD

Old Slot

• TBD

List of tests needed:

• Can register
• can unregister
• cannot re-register
• Cannot unregister if doesnt exist
• Can withdraw funds
• Can automatically withdraw periodically
• unregister sends any balance/withdraw full storage deposit
• Can start pending, go to active
• Can be active and be dropped for not participating
• Can be active and be flagged for drop but reset itself for being active

Agents:

Register Agent

Unegister Agent

Update Agent

Withdraw Agent Balance

Agent becomes active

Agent missed slots, needs to eject

Agent becomes active, but doesnt do tasks

Agent becomes active, but doesnt do tasks

Talking through options about how to fix it, here's some notes:

• Limit ratio of agents to tasks, round robin, missed race with implied potential loss
• sweeper idea: a single elected agent to cover all the floor key tasks
• multiple sweepers can pay and sometimes be paying just fees, but can recover their status as main agent
• kick agents that missed X number of tasks

Treasury contract:

• calculate available deposits / needed usable deposit funds
• stake
• unstake
• get totals
• transfer NFT
• transfer Token
• deposit token
• swap token
• withdraw token
• convert flow for accepting tokens
• withdraw flow for agents earning tokens instead of NEAR

Account for failed txn fee in proxy_call, so agent balance is not affected.

Appears 0.00059 NEAR - failed TXN cost

See:

Available Tasks: 1, Current Slot: 52226640
Receipt: EyBySwPJ19oM8sN5uvSW2RzHDZPxiUnkLmQ6PudVdcbh
	Log [cron.in.testnet]: current slot 52226640
	Failure [cron.in.testnet]: Error: {"index":0,"kind":{"ExecutionError":"Smart contract panicked: panicked at 'No tasks found in slot', manager/src/lib.rs:450:14"}}

Do not allow scheduling within current slot upon creation

When querying how many active tasks, the lookup has the logic:

• how many in current slot
• OR how many in the floor key slot

This returns false counts of tasks, which actually should SUM these two.

See source: https://github.com/Cron-Near/contracts/blob/main/manager/src/lib.rs

Goals:

• comb for obvious things like overflows, logical gaps, etc.
• comb for known vulnerabilities
• comment on best practices
• comment on areas of improvement
• provide suggestions for efficiency, safety etc.

Task get stuck when (A: scheduled and then gets exited not removing hash correctly) (reproduce: Remove a task before its done, slot remains)

Tasks:

Create Task

• TBD

Refill Task

• TBD

Remove Task

Idea:

• What if tasks fall through the cracks? Should there be a way for admin to clear tasks by a slot id?

Views:

Info

• Use get_info & version methods to check the currect contract status. Validate the returned fields from get_info against defaults & bounds to ensure contract is properly configured. Example: If there are 7 active agents and 4 tasks, with a task ratio of [1,2] then there is a problem (it would expect 14 tasks).

Validate Cadence

• TBD

Get Task Hash

• TBD

Bootstrap:

Deploy

• deploy and call "new", no args

Configure Settings

• update_settings can handle many different parameter adjustments, confirm that they can be set and error appropriately:
  • change owner_id
  • update slot_granularity and check previous slots are still possible to execute
  • paused - make sure this locks the right functions
  • do basic param change checks on the rest of the arguments supported: [owner_id, slot_granularity, paused, agent_fee, gas_price, proxy_callback_gas, agent_task_ratio, agents_eject_threshold]

Simulations

• Agent startup: create new keys, register as agent, run task
• Agent ongoing: run 10+ tasks at diff block ranges
• Agent reward: run 10+ tasks, withdraw reward balance
• Agent stop: stop tasks, withdraw balance, unregister
• 1 Time Task: Create task with minimum balance
• 10 Time Task: Create task with balance for 10 tasks
• Refilled Task: Create task with 3 execution balance, add balance after creation, make sure it runs more than 3 times
• Stopped Task: Create task, execute 3 times, owner stops task, make sure it doesnt run again
• Gas Calculation: Simulate all gas execution needs

Appears tick throws off the accuracy of BPS.

Change Tick to have 2 items in an array, so we can always have ~1000 blocks distance for better average.

See the following:

Receipts: 5tmLRf111bKzjVPpTgennn6Ne1f1uWsqxYNi3puzr6eF, 33EJkMmUQB7R774jYpPpkksS6YhZ9B53DkFbfCm78eY3, EdGnPe3nYnancgrgK23tGg9UAi3KTMyWYiLzYDpjAcHS
	Log [cron.in.testnet]: current slot 53601660
	Log [cron.in.testnet]: slot [[13, 52, 238, 24, 39, 136, 174, 243, 153, 231, 158, 97, 103, 236, 50, 194, 225, 5, 140, 158, 193, 35, 182, 146, 228, 101, 127, 53, 195, 84, 52, 213]]
	Log [cron.in.testnet]: Found Task Task { owner_id: "cron.in.testnet", contract_id: "cron.in.testnet", function_id: "tick", cadence: "0 0 * * * * *", recurring: true, total_deposit: U128(5000000000000000000000000), deposit: U128(0), gas: 2400000000000, arguments: [] }
Receipt: HBeB7qKoMVEJTBW8pdXoZtLRUVEDgsuZzXRXRaqwBPR9
	Log [cron.in.testnet]: Balances: Available 0, Staked 0
Receipt: GH9Uw8RR9aXgtKsrkE7Q1FZLmfX8AfSjBdYStMjVZbMF
	Log [cron.in.testnet]: Task DTTuGCeIrvOZ555hZ+wywuEFjJ7BI7aS5GV/NcNUNNU= completed successfully
	Log [cron.in.testnet]: Scheduling Next Task 53601720
2021-07-01T05:59:52.780Z Available Tasks: 1, Current Slot: 53601720
Receipts: 2gLYB6k32DaMUF1vmMXbbPf5KeXzC1jK4oDXpK7ox2QF, CqbytYoQmiMvoVztYx4Qk67WmRaeX3GwD2qEDyNVLtMD, yKsqySRTjiKF6VbX9sJoQsrGiRyhrrroYX94q3xYknk
	Log [cron.in.testnet]: current slot 53601720
	Log [cron.in.testnet]: slot [[13, 52, 238, 24, 39, 136, 174, 243, 153, 231, 158, 97, 103, 236, 50, 194, 225, 5, 140, 158, 193, 35, 182, 146, 228, 101, 127, 53, 195, 84, 52, 213]]
	Log [cron.in.testnet]: Found Task Task { owner_id: "cron.in.testnet", contract_id: "cron.in.testnet", function_id: "tick", cadence: "0 0 * * * * *", recurring: true, total_deposit: U128(4999999999988507123382818), deposit: U128(0), gas: 2400000000000, arguments: [] }
Receipt: 39W5H5NrT6ojdBaD4P92xqkz9vUhDnWTEEKxoFUdhGZf
	Log [cron.in.testnet]: Balances: Available 0, Staked 0
Receipt: 2CaWxpGbM891x9ZwQ2it2cDGpTvvLe3CQd8dr91sKx8J
	Log [cron.in.testnet]: Task DTTuGCeIrvOZ555hZ+wywuEFjJ7BI7aS5GV/NcNUNNU= completed successfully
	Log [cron.in.testnet]: Scheduling Next Task 53601780
2021-07-01T06:00:28.605Z Available Tasks: 1, Current Slot: 53601780
Receipts: 3ow6jf8q4xKz2ZUrj7twEZ2fvGuP8viUboDSrJ4JdqGS, 2LstCHc2FdDkZ7Tne2HNYxt2ykmmg96BizWMCsS12R66, BjLxdmptMjyV7FE1DoQ87sTDiLqC5ZKfobLNxzqYUdRe
	Log [cron.in.testnet]: current slot 53601780
	Log [cron.in.testnet]: slot [[13, 52, 238, 24, 39, 136, 174, 243, 153, 231, 158, 97, 103, 236, 50, 194, 225, 5, 140, 158, 193, 35, 182, 146, 228, 101, 127, 53, 195, 84, 52, 213]]
	Log [cron.in.testnet]: Found Task Task { owner_id: "cron.in.testnet", contract_id: "cron.in.testnet", function_id: "tick", cadence: "0 0 * * * * *", recurring: true, total_deposit: U128(4999999999978096503029414), deposit: U128(0), gas: 2400000000000, arguments: [] }
Receipt: 7XNPvPG6qBimA5YhK4jXXxpNFTLpuXhGeD3QKXgcSKsR
	Log [cron.in.testnet]: Balances: Available 0, Staked 0
Receipt: 7qNHWCYNG3zHNr4gt4EmGxML1jrhghgT9kWtJXXF7uwH
	Log [cron.in.testnet]: Task DTTuGCeIrvOZ555hZ+wywuEFjJ7BI7aS5GV/NcNUNNU= completed successfully
	Log [cron.in.testnet]: Scheduling Next Task 53607420
2021-07-01T06:01:02.907Z Available Tasks: 0, Current Slot: 53601840
2021-07-01T06:01:33.021Z Available Tasks: 0, Current Slot: 53601840

A couple of things to note regarding proxy_call. Both have to do with making sure the next agent doesn't run into the same problem.

• There's an assertion to check if the task is Ready or Complete otherwise it won't continue. We'll want to make sure we take action (probably remove the task) and then panic. Otherwise, the next agent will come across the same problem.

Similar to above, there's a second assertion to see if there's enough balance to execute the job. The next agent will run into the same thing. It seems as though this needs to be caught before it happens. We can check a couple of cases:

• For non-recurring tasks, a task should panic if the given deposit is too low.
• For recurring tasks, the task should not reschedule in the future if the balance is too low and instead refund the remainder to the Task's owner_id

Goal:

Create a new page, similar to create task, that allows a user to create a trigger for an associated trigger.

Requirements:

1. Create the UI based on the attached screenshot
2. Create form validations for contract_id, function_id & task_hash
3. before create, validate all fields before submitting transaction.
4. Create Trigger, will use the new method found here, needs to be configured to the right arguments to work. For now, will only work in testnet!
5. Upon create, show the success screen (like create task) but showing the Trigger Hash where the task hash is.

Create Trigger page

An agent can check to execute IF slot is +1 and their index is within range??? (also minus 1 if no tasks to clear old???)

Agent rewards are coming in much smaller than they should:

$ croncat status pa.testnet

payable account id: t.testnet
balance: 0.002090000036
total tasks executed: 12

The main tasks can run and fail continuously, need a param to allow tasks to stop upon first fail. (helps with pagination)