16

It's super simple, from your contract just call the below code: transaction out{}; out.actions.emplace_back(permission_level{_self, N(active)}, N(pet), N(feedpet), std::make_tuple(pet.id)); out.delay_sec = 10; out.send(pet.id, _self); It's basically wrap an action on a transaction object (so you must import eoslib/...


6

You may modify your deferred transaction to call it recursively until remaining_delay is less than max_transaction_delay. The code snippet looks like this. void deferred_txn(uint64_t delay,string sender_id,...){ eosio::transaction txn{}; uint64_t max_delay = 3888000; //max delay supported by EOS if (delay <= max_delay){ /...


5

Yes, you can do that. It's handled by the delay_sec property of the transaction structure. Check this answer: https://eosio.stackexchange.com/a/389/54 If you are using EOSRPC or inside the contract code, just change the delay_sec.


5

The sender_id is just a value set by the contract that sends the deferred transaction so that later operations can refer to the same transaction. The semantics are: sending a new transaction with the same sender_id as one in-flight will replace the in-flight transaction canceling a transaction can be achieved by passing that sender_id into cancel_deferred ...


5

Global variables are more or less a design thing. I personally do not like them because of object-orientation for languages like c++. They are good for script languages, but if your application or contract gets complex, things get complicated and they are hard to maintain. However you do not have to worry about access of our global variable because of the ...


4

So I found a way to access deferred transactions using the following command: curl NODE_HERE/v1/chain/get_scheduled_transactions --data '{"json":"true","limit":-1}' after this, you would have to filter the results to get the deferred transaction that you want.


4

as Nirdesh alluded to in the comments, when a transaction is deferred, it is run by the eosio account and therefore that account needs to be given permission to make the call. Nirdesh's solution above is more complete but the very minimum required to make it work is: cleos set account permission --add-code t active where t is the name of the account that ...


3

Update 19th September: v1.3.0 added a --delay-sec flag to cleos push action so you can now set a delay for your action from cleos directly. I can't see anything in programs/cleos/main.cpp that would allow this directly. The only way that I can think of to do this via cleos is to push an action to a contract that allows you to send deferred transactions; ...


3

Todd Fleming answered this in the EOS Developers Telegram channel as follows: Todd Fleming There isn't an intrinsic to do it. Flag seems like a good option. Refering to Gassa's answer about setting a flag. Me: Thanks. What if it's important to distinguish 1) dropped transactions and 2) transactions that executed but failed due to an assertion error? ...


3

You can add an intermediate deferred transaction that will have a counter and manage the extended time you want to defer to. Say for example that you want to delay for 365*24*60*60*2 = 63072000 blocks which is about a year, create an action that will save this number in your multi_index and call a deferred transaction for the max delay possible 3888000. ...


3

You need to call the transfer action of eosio.token contract with the appropriate arguments after your preferred delay: void send(account_name from, account_name to, asset amount, string memo, uint64_t delay) { eosio::transaction t{}; t.actions.emplace_back( eosio::permission_level(from, N(active)), // with `from@active` permission ...


3

void send(const uint128_t& sender_id, account_name payer, bool replace_existing = false) First parameter(sender_id) is the id of the deferred transaction. You can call cancel_deferred(sender_id) to cancel it. See example in delegate_bandwidth on GitHub.


2

If I understand your question correctly, you can send a deferred transaction like you usually would but defining the delay as a function parameter: void send(account_name account, std::string message, uint64_t delay) { eosio::transaction t{}; t.actions.emplace_back( eosio::permission_level(account, N(active)), N(othercontract), ...


2

I don't know about the proposed solution (the onerror part of the question). This answer deals differently with the original problem. At the very least, the original action can maintain a flag in the RAM, and the deferred one can clear that flag upon completion. It might naturally be more than just a flag, depending on what you want it to do. A practical ...


2

If an action is initiated by user account, it will be included in the trx.trx.actions array of a transaction. Follow this idea, we could do: We have a output actions list from your cleos get actions <dApp account name> -j command. We would like to know that, for each action in the list, is it a user action or an inline action. So we should iterate ...


2

You can delay a transaction. While using cleos just add --delay-sec [seconds to delay] and probably cleos wallet lock will stop cleos from pushing the transaction as long as you're within the delay but that doesn't really sound like a way one should go.


1

Change std::make_tuple(itr) to std::make_tuple(*itr). The type of itr is const_iterator and it's not serializable.


1

Yes you can use cleos to do the delay send by adding the option: --delay-sec [seconds to delay] And no it does not lock up your eos, it will just fail when that time comes to send it.


1

Answer from the telegram by admin Todd Fleming: There is no guarantee that delayed transactions will execute on time, or at all. Trying to make guarantees like that would compromise the integrity of the chain.


1

No, the success or failure of the deferred transaction is independent of the action in which it is called. The only exception is if the deferred transaction would objectively fail in the original action. For example if your deferred transaction would transfer more money from the account than is actually stored there at the time of calling the deferred ...


1

It isn't possible to call a non-ABI action in the way you want. Only something in the ABI can be called in a transaction, whether it is deferred or not.


1

To resend failed transaction you have to unpack it from onerror struct and resend it. transaction failed_tx = error.unpack_sent_trx(); failed_tx.send(tx_id, self); see also proxy contract


1

I have found a solution to my problem. The problem was caused by the fact that the delegatebw function implicitly calls the transfer function from the contract to the receiver. This, combined with the fact that we have a listening function that waits for transfers to occur and doesn't distinguish between transfers to the account and transfers ...


1

I'm not quite sure in your code what's account1 as it's not defined anywhere. Did you mean N(account1)? Also, what does account1::transfer() look like? Are you trying to transfer EOS tokens? You should probably be using eosio.token as the account to which you send the action then. Here's an example of a contract that manages the transfer of tokens #include ...


1

What's tester and tester::hello() looking like? Your code may look ok or not depending on how those are implemented. Any small error may result in the whole thing failing with no helpful error message. Here's a full example of something that works on my machine fine: sender.cpp #include<eosiolib/eosio.hpp> #include<eosiolib/transaction.hpp> #...


Only top voted, non community-wiki answers of a minimum length are eligible