Support for Additional Node.js Arguments

[dajneem23]

Describe the feature

To improve the flexibility of Node custom script

Some proposed arguments to support:

• --env-file=file / --env-file-if-exists=file → load environment variables directly from file

• --max-old-space-size=SIZE → control memory usage for larger projects

• UV_THREADPOOL_SIZE

This would help developers configure environments, debug issues, and optimize performance more seamlessly when running openzeppelin-monitor.

Thanks

Additional context

I also want to take charge of this

[shahnami]

@dajneem23 - Looking back at the code, I can see we do support passing arguments as part of the script notification setup. For example in: /examples/config/triggers/script_notifications.json:

{
  "evm_large_transfer_usdc_script": {
    "name": "Large Transfer Action",
    "trigger_type": "script",
    "config": {
      "language": "Bash",
      "script_path": "./config/triggers/scripts/custom_notification.sh",
      "arguments": ["--verbose"],
      "timeout_ms": 1000
    }
  }
}

Is this what you mean, or is there another use-case I'm missing?

[dajneem23]

@dajneem23 - Looking back at the code, I can see we do support passing arguments as part of the script notification setup. For example, in: /examples/config/triggers/script_notifications.json:

{
  "evm_large_transfer_usdc_script": {
    "name": "Large Transfer Action",
    "trigger_type": "script",
    "config": {
      "language": "Bash",
      "script_path": "./config/triggers/scripts/custom_notification.sh",
      "arguments": ["--verbose"],
      "timeout_ms": 1000
    }
  }
}

Is this what you mean, or is there another use case I'm missing?

@shahnami Following my inspection, the current implementation of JavaScriptScriptExecutor

#[async_trait]
impl ScriptExecutor for JavaScriptScriptExecutor {
	fn as_any(&self) -> &dyn Any {
		self
	}
	async fn execute(
		&self,
		input: MonitorMatch,
		timeout_ms: &u32,
		args: Option<&[String]>,
		from_custom_notification: bool,
	) -> Result<bool, anyhow::Error> {
		// Create a combined input with both the monitor match and arguments
		let combined_input = serde_json::json!({
			"monitor_match": input,
			"args": args
		});
		let input_json = serde_json::to_string(&combined_input)
			.with_context(|| "Failed to serialize monitor match and arguments")?;

		let cmd = tokio::process::Command::new("node")
			.arg("-e")
			.arg(&self.script_content)
			.stdin(Stdio::piped())
			.stdout(Stdio::piped())
			.stderr(Stdio::piped())
			.spawn()
			.with_context(|| "Failed to spawn node process")?;
		process_command(cmd, &input_json, timeout_ms, from_custom_notification).await
	}
}

In this implementation, the arguments are passed as args, not as command-line arguments (as outlined in the Node.js CLI documentation). Additionally, we can access the environment from process.env in the main thread. I believe it would be more flexible to allow more arguments to be passed to the Node.js process, as I mentioned earlier above

[shahnami]

You're right, good catch. I'll assign this to you if you're still interested.

[dajneem23]

i will do, thank you !!