Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index xcm tasks #28

Open
wants to merge 17 commits into
base: staging
Choose a base branch
from
Open

Index xcm tasks #28

wants to merge 17 commits into from

Conversation

v9n
Copy link
Member

@v9n v9n commented Jan 29, 2024

I think the idea is to save disk space, we skip index event from parachainSystem' && extrinsicMethod === 'setValidationData

Unfortunately the XCM task event is through that extrinsic, so we have been missing the XCM tasks in our data.

project.yaml Outdated
@@ -18,7 +18,8 @@ schema:
network:
endpoint: 'wss://rpc.turing-staging.oak.tech'
chainId: '0xd54f0988402deb4548538626ce37e4a318441ea0529ca369400ebec4e04dfe4b'
#dictionary: "https://api.subquery.network/sq/subquery/kusama-dictionary"

dictionary: "https://api.subquery.network/sq/subquery/kusama-dictionary"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're using subql 2.0 but the project has been update and the default discover url is no longer valid subquery/templates@e28f826 so we explicitly set it here.

Copy link
Member

@chrisli30 chrisli30 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks no problem to me.

Copy link

socket-security bot commented Jan 30, 2024

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert Package NoteSource
Install scripts npm/[email protected]
  • Install script: postinstall
  • Source: node scripts/postinstall
Native code npm/[email protected]
Install scripts npm/@substrate/[email protected]
  • Install script: postinstall
  • Source: node build-js-specs.mjs
Install scripts npm/@substrate/[email protected]
  • Install script: postinstall
  • Source: node build-js-specs.mjs
Install scripts npm/@cosmology/[email protected]
  • Install script: postinstall
  • Source: node scripts/postinstall
Install scripts npm/[email protected]
  • Install script: postinstall
  • Source: node scripts/postinstall

View full report↗︎

Next steps

What is an install script?

Install scripts are run when the package is installed. The majority of malware in npm is hidden in install scripts.

Packages should not be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead.

What's wrong with native code?

Contains native code which could be a vector to obscure malicious code, and generally decrease the likelihood of reproducible or reliable installs.

Ensure that native code bindings are expected. Consumers may consider pure JS and functionally similar alternatives to avoid the challenges and risks associated with native code bindings.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

@v9n
Copy link
Member Author

v9n commented Jan 30, 2024

I looked at the alert of Socket Security.

These are expected and normal. there is no known vulnerabiliry in that package but the way that package works:

  1. we had package that has native code (C binding)
  2. package define post install script

These aren't direct dependencies we pull it but our indirect dependencys of subql or substrate.

many node js package use those post install script(it's a risk) but it's popular in node somehow.

CleanShot 2024-01-30 at 10 25 53

@@ -2,7 +2,7 @@ version: "3.9"

services:
subquery-node:
image: onfinality/subql-node:v2.5.1
image: onfinality/subql-node:v3.5.0
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisli30 have to upgrade to get the re-indexing work

record.idx = idx
record.module = event.section
record.method = event.method
const record = new Event(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new subql codegen change how we initialize these objects

@v9n
Copy link
Member Author

v9n commented Jan 30, 2024

@chrisli30 Deployment plan

Up till now, many of our chances can be migrated with purely SQL data manipulation. But this is the first deployment where we were missing data, so we will need to backfill and reindex data from the archive rpc node.

After observation the behavior of turing staging, this is our plan:

  1. We will deploy this code to production: so new data will immediately become effect but we don't have old data yet. so our app can continue to serve traffic
  2. We will run a second node manually call canary node:
 -f=/app
      - --db-schema=canary-turing
       - --log-level=${LOG_LEVEL:-info}
      - -workers=4

Once we have that data, we will

  1. stop all indexer
  2. rename turing-> turing-old`
  3. rename canary-turing -> turing

Restart the indexer which now point to the new schema with the right history data.

@chrisli30
Copy link
Member

@chrisli30 Deployment plan

Up till now, many of our chances can be migrated with purely SQL data manipulation. But this is the first deployment where we were missing data, so we will need to backfill and reindex data from the archive rpc node.

After observation the behavior of turing staging, this is our plan:

  1. We will deploy this code to production: so new data will immediately become effect but we don't have old data yet. so our app can continue to serve traffic
  2. We will run a second node manually call canary node:
 -f=/app
      - --db-schema=canary-turing
       - --log-level=${LOG_LEVEL:-info}
      - -workers=4

Once we have that data, we will

  1. stop all indexer
  2. rename turing-> turing-old`
  3. rename canary-turing -> turing

Restart the indexer which now point to the new schema with the right history data.

Thank you Vinh. Yes, that looks good. 👌

@chrisli30
Copy link
Member

many node js package use those post install script(it's a risk) but it's popular in node somehow.

Got it. Okay, let’s skip those alerts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants