Motivation

The current Release Github Action consists of multiple operations. Among them there’s a step for building and publishing an image to Dockerhub. The Docker image is for community collators to download and update their node program. Due to the fact that Dockerhub doesn’t have a Draft status simple to that of Github Release, we might not want users to see the published Docker image before the build is fully tested on Staging and Turing.

Suggested Solution
I suggest to extract the Dockerhub publish operation out of the release Github Action, and create a separate Action for it. That way we can publish a docker image at the very end of the release procedure, after testing is completed.

I need rapo hashQuestion

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?

Hello,

I tried to run Turing collator with relay-chain-rpc-url flag to specify a remote relay chain RPC to be used instead of the embedded one but the node process ignores it and starts syncing relay chain locally.

Here is the example setup:

ExecStart=/usr/local/bin/polkadot \
  --name Polkadotters \
  --base-path '/var/lib/turing' \
  --execution wasm \
  --wasm-execution Compiled \
  --chain turing \
  --collator \
  --force-authoring \
  --node-key-file /home/polkadot/node_key \
  --trie-cache-size 0 \
  --relay-chain-rpc-url ws://178.170.48.153:9944 \

Probably updating dependencies to 0.9.32 and above should fix this paritytech/cumulus#1585

Actual

When the current price = 100, a task scheduled with condition > 100 will trigger immediately.

Conversely, if the same task is created when price = 80, it is not be triggered when price is moved to 100 (which is the correct behavior).

The condition is "gt", 100, shown in the encoded call of task creation:

0xc8051c73686962757961206172746873776170145752535452105553445458b02965000000000000000000000000086774046400000000000000000000000000000003010100411f03000003010100411febe1aee309491d00000000000000000089051200000c720beb3f580f0143f9cb18ae694cddb767161060850025a57a4f72a71bf475010040007c13030000000000000000000000000000000000000000000000000000000000a17e7ba271dc2cc12ba5ecf6d178bf818a6d76eb0000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000005446cff2194e84f79513acf6c8980d6e60747253000000000000000000000000000000000000000000000000018abef7846071c700000000000000000000000000000000000000000000000000000000000000020000000000000000000000007d5d845fd0f763cefc24a1cb1675669c3da62615000000000000000000000000e17d2c5c7761092f31c9eca49db426d5f2699bf000076b14ea3f010e8c0300076b3c552e020e8c13000c720beb3f580f0143f9cb18ae694cddb767161060850025a57a4f72a71bf475

Repro

This problem can be reproduced by https://github.com/OAK-Foundation/automation-price-demo

In the latest client version v2.1.0 there is a problem in RPC port configuration.

The embedded relaychain always claims port number 9944 - even if you configure a different port for it.
Port 9944 should be available for the parachain as it has ever been.
Instead the parachain is spawning on random ports like 36261 where the RPC is not accessible from the localhost.
The RPC returned the following error while trying to query:
Provided Host header is not whitelisted.

Steps to Reproduce

Start the node client in a minimal setup like the following command to reproduce the issue:

/path/to/oak-collator --collator --chain turing --rpc-port 9944 -- --rpc-port 9945

You will notice that the port configured for the parachain will be assigned to the embedded relaychain instead.

• Operating system: Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-89-generic x86_64)
• Template version/tag: oak-collator 2.1.0-f38b3cd002f

I’m learning about Web3 with EasyA! See if you can complete these challenges! https://links.easya.io/links/NzFg

Description

We recently found that council.setMembers() extrinsic couldn’t successfully due to scheduler’spermenantlyOverweight error during governance referendum execution. This issue started to happen after Turing’s v1.9.0 release mostly due to the introduction of proofSize in Weight struct.

The solution is to change the below constant variable so it’s updated during the next release.

Turing’s current calculation:
https://github.com/OAK-Foundation/OAK-blockchain/blob/0ebac6996c25d8d721bc34912adba39d5e595b6d/runtime/turing/src/lib.rs#L747

Shiden’s calculation for reference:
https://github.com/AstarNetwork/Astar/blob/c9afb955bbed7afb7158899737505a8c6cc3a2a2/runtime/shiden/src/lib.rs#L173

I think we can just increase the percentage, currently at 10%, to higher to approximately equate to 2,048,000 proofsize.

Steps to Reproduce

https://polkadot.js.org/apps/#/explorer/query/0xa66312c8b29966a47059aa63dc53cdb1f36b674c9b5183723520fd07be1bd4c7

Expected vs. Actual Behavior

A simiple council.setMembers() call should pass and not encounter scheduler.permenantlyOverweight error.

Environment

The issue was found on Turing Staging.

I’m learning about Web3 with EasyA! See if you can complete these challenges! https://links.easya.io/links/f4VE

When calling extrinsics and querying system events, I find it’s cumbersome but to have two sets of names. For example, in events of automationPrice, who and taskId are used, but in data storage, it becomes taskId, ownerId.

TaskScheduled Event
{ who, taskId }

automationPrice.tasks
{
ownerId: 6757gffjjMc7E4sZJtkfvq8fmMzH2NPRrEL3f3tqpr2PzXYq
taskId: 1549-0-1
...
}

I think we should define a standard for those names.

1. The who is not a good name, because both owner and scheduleAs are "who"s. We should just call the creator of the task, "owner".
2. The "taskId" seems good so far.

A reminder that if we change the "who" to "owner" in events, we will need to update automationTime and data Insights service as well.

Question

Hi , Please help me regarding it - How to deploy my ink smart contract over turning network parachain in polkadot url- "https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.turing.oak.tech#/settings".

OAK Improvement Proposal

Note: this proposal will be deprecated by #387 since we won’t need to create special Event such as AutoCompoundDelegatorStakeSucceeded any more

Motivation

The goal of this proposal is to create a standard for Event and Error definition, in order to properly organize the Rust code and simplify live debugging process. The current problem is that Event such as TaskScheduled doesn’t carry sufficient information for developers to tell what type is the event and who is it for. Although we can retrieve the full information from the original creation extrinsic with the taskId, the lookup method is clumsy and not intuitive. With this proposal, we aim to unify the format of the Task related events, and let me carry more meaningful information.

Suggested Solution

Extend default Rust struct such as DispatchErrorWithPostInfo struct in Substrate.

For example,
The AutoCompoundDelegatorStake events are defined in automation-time/src/lib.rs. In order to standardize their format I propose changes as below,

Success Events
Name: AutoCompoundDelegatorStakeSucceeded
Attributes:

• who: the creator of the task
• taskId: the id of the task
• collator: the collator the auto-compound is delegated to
• amount: the amount of compound staked in this execution

Error Events
Name: AutoCompoundDelegatorStakeFailed
Attributes:

• who: the creator of the task
• taskId: the id of the task
• DispatchErrorWithData, in which the struct contains
  • message:
  • data: []

For example, if the failure reason is "not enough wallet balance to pay for execution fees", then message is Unable to pay fees for the next execution and the data vector contains only one item, which is a float number, or string with the value of <fee_amount_to_deduct>. The entire Event will look like below,

Name: AutoCompoundDelegatorStakeFailed
Attributes:

• who: the creator of the task
• taskId: the id of the task
• DispatchErrorWithData
  • message: Unable to pay fees for the next execution
  • data: [<fee_amount_to_deduct>]

Another example would be "no delegation to the specified collator", meaning the wallet doesn’t have an active delegation to the collator specified during task creation. It’s very likely that the wallet has unstaked from that collator. Then, the message should be "Active delegation to collator not found", and the data vector would contain only one item, which is the wallet address of the collator. The entire Event will look like below,

Name: AutoCompoundDelegatorStakeFailed
Attributes:

• who: the creator of the task
• taskId: the id of the task
• DispatchErrorWithData
  • message: Active delegation to collator not found
  • data: [<collator_wallet_address>]

Description

The logic of test missed_tasks_removes_completed_tasks is incorrect.

First, we haven't tested the process of a task being missed. Can we change the weight of this block to make the weight limit very low, so a task would be missed?

Second, after the task is missed, it should be added to the missed queue. At this point, we should check the contents of the missed queue.

Lastly, in our code, if the next block has weight capacity, will it take tasks from the missed queue and try to execute them? We should check if taskExecuted is present in the next block. Do you understand? The test case should not directly manipulate the missed task queue; instead, the task queue should be handled by the dev code.

Environment

Unit tests in dev environment.

parachainStaking.topDelegations for a specific collator, returns a set of delegators
parachainStaking.delegatorState for 1 of these delegators, returns Unknown
This issue happens only for a specific delegator.

block
0x2979563cd3619ef7307005ff7bd1bd0230533d93b56087bcc04ac662edf4bf6c

collator: 684xNMHJrNNqVT26AB19mPApS2FRAMVspkgALq7WgBAvohho

parachainStaking.topDelegations: Option<PalletParachainStakingDelegations>
{
  delegations: [
    {
      owner: 69ZNQdLopee2ZNDL5xkSKu9QpkQq7jJGgiw9tFjDZVtoLRim
      amount: 1,179,800,000,000,000
    }
    {
      owner: 6AMsXyV1CYc3LMTk155JTDGEzbgVPvsX9aXp7VXz9heC3iuP
      amount: 14,500,000,000,000
    }
    {
      owner: 6BDaap5XLPtgkkkWCBXPzaiRG5BL29E7RMnpGJ685Y4hvvq9
      amount: 12,450,000,000,000
    }
    {
      owner: 67AHmcoC8Rp68b5SzDhf5fpzHmRTAcuEctvciPDEyiA57ons
      amount: 12,170,000,000,000
    }
    {
      owner: 69BMX8xZaWevFhDssG3RiqqDyzrx5uQgVo9XztV5VjMNimr8
      amount: 11,190,000,000,000
    }
    {
      owner: 681wSDNULDV3pduPvWgLxKMvGc3pgiwCimp1dRr9qVtSrfk1
      amount: 10,000,000,000,000
    }
    {
      owner: 6Bu7uoHFwGELfVAxtepJa8xgCevVjtsVdK4nLqnDWEJpPm2E
      amount: 5,110,000,000,000
    }
    {
      owner: 66XWAcwQHXccJcFFY2raBGSzM6EVdCFKiJ5HjEYN7uq5CKq9
      amount: 5,000,000,000,000
    }
    {
      owner: 69mcbb4o9DZCe9hQFxC5jcoHRcZb2ffVeJ14tdqTMTZ7W4E2
      amount: 4,200,000,000,000
    }
    {
      owner: 68sdNVNYXGyrtmiahL2C9v8CfyhjBonpPaeSsgLuS9CEzSmL
      amount: 2,601,204,399,877
    }
    {
      owner: 67kgfmY6zpw1PRYpj3D5RtkzVZnVvn49XHGyR4v9MEsRRyet
      amount: 1,200,000,000,000
    }
    {
      owner: 66ZfMmWxtPXpnY5Rmj9LmzNjVN2veVyzdAqLjrvJiqdxqsS1
      amount: 1,180,000,000,000
    }
    {
      owner: 6BagJrpC13DX6NWJYNqvcaPrgAtfm4L3zf2ZJb8LwBd2y1hK
      amount: 1,100,000,000,000
    }
    {
      owner: 69vGFK17eUH8WjbLs8F59J958Ra6tB1gAiaHEk7JL5mtX8r4
      amount: 1,000,000,000,000
    }
    {
      owner: 679zFkKB2TMwVD7kcQhR7NM8oM2sSenJ5ZTWu91CAt3PF8px
      amount: 840,000,000,000
    }
    {
      owner: 69TJrMGnkqqzyLP2XDK86wRrEnUrKUA7FVbvwM5xemr58uHt
      amount: 510,000,000,000
    }
    {
      owner: 68jM33DoSS7QsYfa75oRizbcyTHs28urFCmWQaEkwZ1QSHPd
      amount: 500,000,000,000
    }
    {
      owner: 6B7ACD3jQPuC2TBC55K7QTedy82TgVGP5H72DyRigkXdkieD
      amount: 500,000,000,000
    }
  ]
  total: 1,263,851,204,399,877
}

delegator:
68jM33DoSS7QsYfa75oRizbcyTHs28urFCmWQaEkwZ1QSHPd

parachainStaking.delegatorState: Option<PalletParachainStakingDelegator>
<unknown>

After migrating Turing node, we couldn't sync the chain from scratch due to inability to connect to any peers.

• tried both --chain turing and download the spec file from github https://raw.githubusercontent.com/AvaProtocol/OAK-blockchain/master/node/res/turing.json
• tried different binary versions like 2.1.4, 2.0.0, 1.7.0

here's the systemd service file we're using:

ExecStart=/usr/local/bin/turing \
  --name Polkadotters \
  --base-path '/var/lib/turing' \
  --wasm-execution Compiled \
  --chain turing \
  --collator \
  --force-authoring \
  --trie-cache-size 0 \
  -- \
  --state-pruning 100 \
  --blocks-pruning 100

Finally we managed to resolve this issue with the help of fellow collator (props to Sik | crifferent.de) who made a bootnode to connect to.

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?
What is the first commit hash that was ever made in the main oak GitHub repo?

Steps to Reproduce
Take the task 4353492-0-1 on Turing Network as an example.

Run the below query in Insights,

SELECT block_height, id, timestamp, module, method, docs, data, extrinsic_id
FROM turing.events 
where data::text LIKE '%67gFKvqXtE5bx1E98uV6yhR9wosktNQQZyf5HdncHzvCqbUB%' AND module NOT IN ('balances','parachainStaking')
order BY block_height DESC;

You will see the TaskTriggered event, which contains the encodedCall

{'who': '67gFKvqXtE5bx1E98uV6yhR9wosktNQQZyf5HdncHzvCqbUB', 'taskId': '4353492-0-1', 'condition': {'type': 'time', 'timestamp': '1706074800'}, 'encodedCall': '0x1f00c60e71bd0f2e6d8832fea1a2d56091c48493c78801006808338e4789af9cef672b34662a6f74d0486439e4612aa5f4aa8b057f283a81c6de8aaf72cd471300008a5d78456301'}

Expected vs. Actual Behavior

The encodedCall 0x1f00c60e71bd0f2e6d8832fea1a2d56091c48493c78801006808338e4789af9cef672b34662a6f74d0486439e4612aa5f4aa8b057f283a81c6de8aaf72cd471300008a5d78456301 is not a hash that can be decoded by Turing. It is not the direct payload of the Turing task. Instead, it is the XCM payload of task payload. In this case, it is a hash on Moonriver, https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmoonriver.api.onfinality.io%2Fpublic-ws#/extrinsics/decode

We expect the direct payload of the task in encodedCall, one that can be decoded by Turing. Inside that payload, it contains the information of XCM, indicating the destination of the message. That’s how we will know that the XCM payload is for Moonriver, and then we can use Moonriver adapter to decode the inner encodedCall.

Steps to Reproduce

1. Submit an extrinsic to delete an asset
   Encoded call hash: 0xdfb4ba0568a5b12c4abe449f9d7f155bbfea51ed96b923103f98a7926e3cce91

2. The AssetDelete event shows up, but only with one asset in its details.
   

3. The original asset is still in chain storage
   

4. Although the delete extrinsic succeeded, re-create the same asset will get an "automationPrice.AssetAlreadyInitialized" error during extrinsic submission.
   initAsset Encoded call hash: 0xc8011c73686962757961206172746873776170145752535452105553445412040c720beb3f580f0143f9cb18ae694cddb767161060850025a57a4f72a71bf475

Vinh, since you separated Action script recently, I’m assigning this item to you. There seems to be several Github Actions script deprecated. Could you check them out in the below screenshot to see if my requirements make sense?

Regarding the renaming, I think "Publish Turing Docker Image" is good enough. In addition, it would be also great to include the docker image name oaknetwork/turing in its title or description.

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?

In automationTime, there’s a specific RPC interface for querying fees. Although fee logic in automationPrice is simple at the moment, I think we still need an interface to return the actual fee deducted for schedule + execution. Please check the code of query_fee_details of automationTime to see if a similar interface is required for automationPrice

For example, this is the interface for developers, auto-generated by the chain’s RPC metadata.
https://github.com/OAK-Foundation/oak.js/blob/22ae77e28aa40b9f69158cc750a2c5841dc34d4c/packages/types/src/automationTime.ts#L26C4-L32C7

From developer’s perspective, every data type in on-chain storage needs a unique id, otherwise there’s no way to know whether a Price has been updated. Please refer to the screenshot below, as you can see from the events the client couldn’t tell what server version the data entry is.

A Place holder to keep track of progress and TODO to be fully consider the feature is completed

• Add benchmark and update weight for automation-price pallet
• Cleanup TODO
• Handle delete asset extrinsic
• Improve error handling
• Optimize price trigger performance: only scan/check asset that has price actually move in the same directon with the triggering function.
• General code cleanup
• Simplify interface API(There will be a goole doc next to discuss those) https://docs.google.com/document/d/1JIKL0BrKAZTKWzeNdoMrtb9OJ6elDmePCpDBaUlVejY/edit

Add relevant event similar to Automation Time

• TaskCancelled
• TaskCompleted
• TaskExecuted
• TaskExecutionFailed

Sub PR:

#420

Description

Nova wallet tested the on Turing Staging. However, I found that although the taskId is 2181496-2-3, the taskScheduled event Id is 5, different from the last number in taskId 3.

All events regarding task 2181496-2-3, indicating the TaskScheduled eventId is 3.

The block of 2181496, where TaskScheduled eventId is 5.

Action

1. We need to re-create this block and re-produce this issue using unit test.
2. We need to review the dev code that determines the eventId of task creation to see if the last number eventId can be accurately calculated.

I’m learning about Web3 with EasyA! See if you can complete these challenges! https://links.easya.io/links/ixZu

According to the chain consensus design. If more than 1/3 validators failed to produce blocks, the blockchain stops and can't be recovered. Below are issue references to that issue and a hack Darwinia came up with to get around it.

Similar issue on Substrate
paritytech/substrate#4464

Darwinia's workaround
darwinia-network/darwinia@ce4ce7a#diff-d2bd7cb542d4338238e9e420d754e1cbR72

Description

Due to the relay chain upgrading to polkadot-sdk 1.11.0. The existing relay chain in zombienet configuration needs to updated. We need to test all zombienet configuration and update them.
https://github.com/OAK-Foundation/OAK-blockchain/tree/master/zombienets/turing

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?

Let’s clean up the definitions of tokens in AssetRegistry in dev environment.

Requirements:

1. Add Relay Chain token to assetRegistry
2. Remove SDN, RSTR from the array, because they are never used in dev environment, right?

The current values I see from running a dev chain.

[
  [
    [
      5
    ]
    {
      decimals: 18
      name: Moonbase
      symbol: DEV
      existentialDeposit: 1
      location: {
        V3: {
          parents: 1
          interior: {
            X2: [
              {
                Parachain: 1,000
              }
              {
                PalletInstance: 3
              }
            ]
          }
        }
      }
      additional: {
        feePerSecond: 10,000,000,000,000,000,000
        conversionRate: null
      }
    }
  ]
  [
    [
      1
    ]
    {
      decimals: 18
      name: Mangata Rococo
      symbol: MGR
      existentialDeposit: 0
      location: {
        V3: {
          parents: 1
          interior: {
            X2: [
              {
                Parachain: 2,110
              }
              {
                GeneralKey: {
                  length: 4
                  data: 0x0000000000000000000000000000000000000000000000000000000000000000
                }
              }
            ]
          }
        }
      }
      additional: {
        feePerSecond: 416,000,000,000
        conversionRate: null
      }
    }
  ]
  [
    [
      2
    ]
    {
      decimals: 18
      name: Rocstar
      symbol: RSTR
      existentialDeposit: 10,000,000,000,000,000
      location: {
        V3: {
          parents: 1
          interior: {
            X1: {
              Parachain: 2,006
            }
          }
        }
      }
      additional: {
        feePerSecond: 416,000,000,000
        conversionRate: null
      }
    }
  ]
  [
    [
      0
    ]
    {
      decimals: 10
      name: Native
      symbol: TUR
      existentialDeposit: 100,000,000
      location: {
        V3: {
          parents: 0
          interior: Here
        }
      }
      additional: {
        feePerSecond: 416,000,000,000
        conversionRate: null
      }
    }
  ]
  [
    [
      3
    ]
    {
      decimals: 18
      name: Shiden
      symbol: SDN
      existentialDeposit: 10,000,000,000,000,000
      location: {
        V3: {
          parents: 1
          interior: {
            X1: {
              Parachain: 2,007
            }
          }
        }
      }
      additional: {
        feePerSecond: 416,000,000,000
        conversionRate: null
      }
    }
  ]
  [
    [
      4
    ]
    {
      decimals: 18
      name: Shibuya
      symbol: SBY
      existentialDeposit: 10,000,000,000,000,000
      location: {
        V3: {
          parents: 1
          interior: {
            X1: {
              Parachain: 2,000
            }
          }
        }
      }
      additional: {
        feePerSecond: 416,000,000,000
        conversionRate: null
      }
    }
  ]
]

The issue stores all the images and files needed in this repo

The expiredAt value works well, as tasks are not executed once the block time passes it. However, expired tasks stay in tasks result and are not get cleaned up. It’s not a high-pri but we definitely need to have means to clean them.

(This proposal is being implemented in #383 )

Motivation

First of all, it's important to note that the discussion in this issue applies to only the Recurring Schedule of timeAutomation, but not the Fixed Schedule. However, the concept can later be extended to apply to priceAutomation as well.

Currently, the logic that determines whether a task should be retried is defined in our code. To enhance scalability and delegate design decisions to developers, I propose adding an array called abortErrors to the task creation extrinsics.

By default, when the abortErrors array is empty, a Recurring task will continue retrying upon encountering all errors. For instance, if a parachainStaking.delegatorBondMore fails due to "InsufficientBalance," it indicates that staking has not generated enough reward to compound yet. In this scenario, the task will fire a TaskRescheduled event and retry at the next scheduled time, such as every day. On the other hand, if a user decides to add the string "InsufficientBalance" to the abortErrors array, the task will instead fire a TaskNotRescheduled event and cease to occur altogether.

The array of abortErrors should look like,
abortErrors: ["DelegationFailed", "Insufficient Balance"]

It's essential to consider that errors have priorities, meaning some errors take precedence over others and will terminate the task execution, subsequently blocking other errors from firing.

For instance, suppose the abortErrors parameter includes only a "DelegationFailed" error. In that case, the task should not reschedule when delegation execution fails due to this specific error. However, there might be other execution failures, such as "InsufficientBalance," which occur earlier in the code and are not listed in the abortErrors array. Consequently, the task will continue to reschedule until a "DelegationFailed" error is fired, as it takes precedence in the code flow.

This behavior is normal in the code. As we progress, we will gain more clarity on different situations and provide guidelines to dapp developers on setting the abortErrors parameters optimally, ensuring smooth task executions based on their specific requirements.

By empowering dapp developers to specify errors in the abortErrors array, we offer significant flexibility in determining the conditions that should lead to task abortion. This approach allows for more customization and control over task behavior based on specific requirements.

Additional Information

There are a few things we plan to improve in the future, including:

1. Providing dapp developers with best practices for defining the abortErrors for different type of tasks.
2. Adding special handling logic to tasks to abort by default. In the current design, no error will abort a task by default.

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?

Releases 2.14 binary and source code downloads apparently provide v.2.1.0-e07a5345066.

Steps to Reproduce

wget https://github.com/OAK-Foundation/OAK-blockchain/releases/download/v2.0.0/oak-collator
chmod +755 oak-collator
./oak-collator --version

oak-collator 2.1.0-e07a5345066

Calling system::version() extrinsic through https://polkadot.js.org/apps returns:

2.1.0-e07a5345066

OR

git clone https://github.com/OAK-Foundation/OAK-blockchain.git
cargo build --release --features turing-node --features dev-queue
./target/release/oak-collator --version

oak-collator 2.1.0-e07a5345066

and running Moonbeam EVM smart contract automation demo chokes on Error: The scheduleAs parameter should not be empty, which should not be present in v.2.1.4

Expected vs. Actual Behavior

oak-collator to report as, and operate as, v.2.1.4
vs
reports as oak-collator 2.1.0-e07a5345066 and does not include merged feature of v.2.1.4

Related issue
Moonbeam demo cannot work with required Turing version

Substrate/rust developer here

Contributor on different Substrate/Rust repos: https://github.com/herou
1- Converted substrate all the recipes from frame v1 o v2 : JoshOrndorff/recipes#471 (It took me 6 months)
2- Winner of one of Web3 grants and delivered it on time: w3f/Grant-Milestone-Delivery#599

Let me know!

Description

Tell us what happened. In particular, be specific about any changes you made to this template.
Ideally, provide a link to your project's GitHub repository. Please note that we are not able to
support all conceivable changes to this template project, but the more information you are able to
provide the more equipped we will be to help.

Steps to Reproduce

Replace the example steps below with actual steps to reproduce the bug you're reporting.

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected vs. Actual Behavior

What did you expect to happen after you followed the steps you described in the last section? What
actually happened?

Environment

Describe the environment in which you encountered this bug. Use the list below as a starting point
and add additional information if you think it's relevant.

• Operating system:
• Template version/tag:
• Rust version (run rustup show):

Logs, Errors or Screenshots

Please provide the text of any logs or errors that you experienced; if
applicable, provide screenshots to help illustrate the problem.

Additional Information

Please add any other details that you think may help us solve your problem.

I’m learning about Web3 with EasyA! See if you can complete these challenges! https://links.easya.io/links/PpuJ

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?

Question

Hi there,
I'm from Dwellir, a node provider running a node on the Turing chain, and when I just now tried upgrading our node from v2.0.1 to v2.0.2 I got this error when starting the node client (oak-collator client is renamed polkadot in our infra) after the upgrade:

/home/polkadot/polkadot: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/polkadot/polkadot)
/home/polkadot/polkadot: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/polkadot/polkadot)
/home/polkadot/polkadot: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/polkadot/polkadot)
/home/polkadot/polkadot: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /home/polkadot/polkadot)
/home/polkadot/polkadot: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/polkadot/polkadot)

I couldn't find any info in the latest release notes about any new requirements for this version. My temporary solution was to downgrade to v2.0.1 again, which lets the node run fine, but I do have questions:

• Is this new requirement an intended change?
• What should we install to make the v2.0.2 client work?

Cheers,
Jakob

When an a non-existent taskId, for example undefined, is passed into cancelTask, TaskCancelled currently fails silently, creating confusion on whether the submitted extrinsics executed or not.

It should throw a regular TaskCancelled event indicating a failed cancellation. For example, ProxyExecuted has a good example that when an error happens, it returns the error instead of the actual result.

In automationPrice, the TaskTriggered event doesn’t contain enough data to indicate the trigger condition. Please refer to #387 to implement it similar to the TaskTriggered in AutomationTime

Event Name: TaskTriggered
Attributes:
• taskId:
• who:
• condition: { type:time, value: 1689903366 }

Description

Block 3288719 events cannot be correctly decoded. Event 0 is wrongly decoded as 'TaskExecutionFailed' instead of 'TaskTriggered'

Steps to Reproduce

Replace the example steps below with actual steps to reproduce the bug you're reporting.

1. Go to Polkadot.js apps
2. Try to query block 3288719 https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.turing.oak.tech#/explorer/query/3288719
3. See events decode error

Expected vs. Actual Behavior

Events decoded without errors

Environment

--

Logs, Errors or Screenshots

See https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.turing.oak.tech#/explorer/query/3288719

Additional Information

Subscan has a correct version of this block https://turing.subscan.io/block/3288719?tab=event

In tests such as trigger_tasks_completes_some_xcmp_tasks, we didn’t verify the success event of xcmHandler pallet because there’s no mock for that event. In order to fix that, we need to create a mock deposit_event of xcmHandler.xcmSent and verify the firing of that to mimic the scenarios in production.

OAK Improvement Proposal

Motivation

Looking at the task history on Turing Network, specifically the task with the hash 0xcae095bc2b84249e4ca65671759808e0bb10680fb4fedd1ad9e358e4e084de39 shown in the screenshot below, it is evident that after each execution, both TaskScheduled and TaskRescheduled events contain identical data.

Another issue is that the event of task triggering is intertwined with execution and has no indication of whether to reschedule for the next execution. To address this, I propose the following standard for task events.

For all tasks,
After the creation extrinsic, a TaskScheduled needs to be fired. ✅

During task execution,

1. A TaskTriggered event should be fired to indicate the successful triggering of a task.
   Event Name: TaskTriggered
   Attributes:

   • taskId:
   • who:
   • condition: { type:time, value: 1689903366 }
   • CancelUponError: whether to cancel a task upon execution error. A map of errorCode and true of false, by default all erros are true, meaning the task will be cancelled upon error.
     { "errorCode": true or false}, for example, {"InsufficientBalance": false}

2. Next, the actual logic should run and generate an event for its result, such as , parachainStake.delegationIncreased. This event should resemble the ones triggered by manual signing and should not be related to task events. The event can indicate success or failure, marking the execution result of the task. The execution event index should always be equal to the event index of the above TaskTrigger + 1. Currently, events have different names like XcmpTaskSucceeded and SuccessfullyAutoCompoundedDelegatorStake. We do not need to create special events like these; instead, we can rely on the existing events in the underlying pallets.

3. If the task is a recurring schedule, a TaskRescheduled event should subsequently be fired, indicating that a new task has been paid for and scheduled for the next run. If the user's wallet does not have sufficient fees to pay for the next execution, an error will occur at this step, but it will not stop the execution mentioned above.

These changes offer several benefits:

1. The firing of a task execution is clearly indicated through TaskTriggered, serving as a notification that the triggering function is functioning properly.
2. The success or failure of the execution is independent of the triggering notification mentioned above.
3. The execution logic is separated from the rescheduling process. For a fixed schedule, TaskRescheduled will not fire, while for recurring tasks, TaskRescheduled will fire upon successful events and may or may not fire upon errors. For example, if the AutoCompoundDelegationStake fails due to insufficient balance to pay for the next execution fee, the TaskRescheduled event should still be fired.

Implementing these changes will enhance the clarity and separation of task-related events, providing a more structured and meaningful representation of task execution and rescheduling.