Error setting resourceFile: "Maximum call stack size exceeded"

[russellseymour]

Environment

azure-pipelines-task-lib version: 2.10 & 2.11.1

Issue Description

I am trying to use the setResourceFile method to use the task.json file of my task. To do this I am using __dirname in the TS file, but this is returning null or / which means that the tasklib is looking for my task in /task.json which it cannot find. It then proceeds to error out with ##[error]RangeError: Maximum call stack size exceeded.

I feel there is something fundamental to this in that it is strange __dirname does not have a value. I am also assuming this is something to do with my implementation, but I cannot see what as I am not (as far as I am aware) overwriting the __dirname value. Additionally the __filename is being set to index.js which is not what I was expecting, especially as I do not have an index.js in my extension; is this the path to the script that is running my extension? If so how do I get the actual path to my extension file so I can set the resource file?

(I tested running this without any of my code, I commented out my libs and the run function but I still get the same issue).

This is a screen shot of the output from AzDo:

Expected behaviour

I should be able to set the resource file to my task.json using the __dirname variable.

Actual behaviour

The __dirname var is not being set to the path of my task, which means the tasklib is not able to find the resource file at /task.json. I suspect then it goes off in a loop to look for other files, but it then exceeds the number of times it can do this, hence the error.

Steps to reproduce

1. The following code shows how I am trying to set the resource file before I run the task

// Import the necessary tasks
import * as tl from "azure-pipelines-task-lib"; // task library for Azure DevOps
import * as task from "../common/taskConfiguration";
import * as ex from "../common/executeComponent";
import { join as pathJoin } from "path";
import { sprintf } from "sprintf-js";

// Execute the chosen Chef component command with the specified arguments
async function run() {

  let taskConfiguration = new task.TaskConfiguration();

  // get the parameters for the task, e.g. the settings that have been provided
  await taskConfiguration.getTaskParameters({}, []);

  // create an instance of the executeComponent class
  let executeComponent = new ex.ExecuteComponent(taskConfiguration);

  // perform the execution of the selected command
  executeComponent.Execute();
}

// set the path to the resourceFile
try {
  let resourceFile = pathJoin(__dirname, "task.json");
  tl.debug(sprintf("Resource file path: %s", resourceFile));
  tl.debug(sprintf("Task filename: %s", __filename));
  tl.setResourcePath(resourceFile);

  // run the task
  run ();
} catch (err) {
  tl.setResult(tl.TaskResult.Failed, err, true);
}

2. I compile and then run the task and I get the error as shown in the screen shot above.

As can been seen, this is occurring very early on in running the task, it has not called run() yet (and will not because of the try / catch).

This is a new version of the Chef extension for AzDo that I am working. The repo for the code is https://github.com/chef-partners/azuredevops-chef-extension.

Logs

I am running the task with Debug as well as system diagnostics but the only data I am getting is:

2020-09-29T08:30:44.2724208Z ##[debug]Evaluating condition for step: 'Execute chefclient'
2020-09-29T08:30:44.2725869Z ##[debug]Evaluating: succeeded()
2020-09-29T08:30:44.2726432Z ##[debug]Evaluating succeeded:
2020-09-29T08:30:44.2727598Z ##[debug]=> True
2020-09-29T08:30:44.2728186Z ##[debug]Result: True
2020-09-29T08:30:44.2728726Z ##[section]Starting: Execute chefclient
2020-09-29T08:30:44.2737246Z ==============================================================================
2020-09-29T08:30:44.2737581Z Task         : Execute Chef Component - PREVIEW
2020-09-29T08:30:44.2737878Z Description  : This task allows the execution of any Chef component
2020-09-29T08:30:44.2738139Z Version      : 3.0.25
2020-09-29T08:30:44.2738327Z Author       : Chef
2020-09-29T08:30:44.2738664Z Help         : [More Information](https://chef-partners.github.io/azuredevops-chef-extension/execute-task.html
2020-09-29T08:30:44.2739076Z ==============================================================================
2020-09-29T08:30:44.3971114Z ##[debug]agent.TempDirectory=/home/vsts/work/_temp
2020-09-29T08:30:44.4002734Z ##[debug]loading inputs and endpoints
2020-09-29T08:30:44.4012107Z ##[debug]loading INPUT_COMPONENT
2020-09-29T08:30:44.4026870Z ##[debug]loading INPUT_SUDO
2020-09-29T08:30:44.4030490Z ##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION
2020-09-29T08:30:44.4034139Z ##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION
2020-09-29T08:30:44.4034590Z ##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN
2020-09-29T08:30:44.4037809Z ##[debug]loaded 5
2020-09-29T08:30:44.4050848Z ##[debug]Agent.ProxyUrl=undefined
2020-09-29T08:30:44.4052724Z ##[debug]Agent.CAInfo=undefined
2020-09-29T08:30:44.4053034Z ##[debug]Agent.ClientCert=undefined
2020-09-29T08:30:44.4053358Z ##[debug]Agent.SkipCertValidation=undefined
2020-09-29T08:30:44.4066151Z ##[debug]Resource file path: /task.json
2020-09-29T08:30:44.4068631Z ##[debug]Task filename: /index.js
2020-09-29T08:30:44.4071610Z ##[debug]check path : /task.json
2020-09-29T08:30:44.4111652Z ##[warning]LIB_ResourceFile does not exist
2020-09-29T08:30:44.4122780Z ##[debug]Processed: ##vso[task.issue type=warning;]LIB_ResourceFile does not exist
2020-09-29T08:30:44.4123315Z ##[debug]task result: Failed
2020-09-29T08:30:44.4123920Z ##[error]RangeError: Maximum call stack size exceeded
2020-09-29T08:30:44.4124733Z ##[debug]Processed: ##vso[task.issue type=error;]RangeError: Maximum call stack size exceeded
2020-09-29T08:30:44.4134087Z ##[debug]Processed: ##vso[task.complete result=Failed;done=true;]RangeError: Maximum call stack size exceeded
2020-09-29T08:30:44.4173717Z ##[section]Finishing: Execute chefclient

[github-actions]

This issue has had no activity in 90 days. Please comment if it is not actually stale

[cima]

I am experiencing this issue even locally. I have simulated this but I don't seem to spot neight the cause nor solution.

I stepepd down to .\node_modules\azure-pipelines-task-lib\task.js method getInput(name, required) to line
throw new Error(exports.loc('LIB_InputRequired', name)); where it should have thew just error.

But then it goes down to translations where apparently something (lib.json) isn't loaded and caught itself into a deadly recursion. So yeah in the end it fails, but not in recoveryable manner.

We are at 2.x version currently. Not even bumping to 3.1.2 helped. To wrap it up we do use webpack 4.44.1 to compile the code.

[cima]

I vote for reopening this issue as there is clearly a bug in the code at internal.ts:203 If the translation is missing then you throw localized exception which recursively calls itself where it realizes this translation is missing as well and throws another localized exception ... until the call stack depth is exceeded. This is bug.

My suggestion for line 203 (and similarly for 206) is

_warning("Resource file haven't set, can't find loc string for key:" + key);

the point here is not to call itself and having string as a part of the code to avoid recursion.

At every point you must assume situation that file hasn't been loaded. E.g. when using webpack because there the dynamic loading of translation fails. It'd be btter to require lib.json absolutely, so webpack (an others) would link at least the english version at compile time and had some fallback. English message instead of localized one is much better than crash.

[officialpatterson]

@cima did you find a solution to this? I think I might have the same issue

[cima]

There is no solution. You can only avoid to hit the buggy code by catching all eceptions and sanitize your input so the error is never triggered.

My way to spotting what was wrong has been to debug the code locally and stepping until the crash. There I spotted it couldn't find one pipeline task input value. So I added this value to configuration of my pipeline and thus avoided the error reporting code that trigger the infinite recursion.

This is only a temporary workaround so I can develop my task. Once we release the task for the rest of the team, I won't be able to guarantee correct configuration in pipeline and thus the problem will definitelly occur again.

The only possibility is to fork the repo and fix the code. I wish I know how to nudge maintainer of this repo to give statement. With that statement It'd be possible for me to beg for time to fix it here (via pull request).

[cima]

This is absolutely insane. This issue must be reopened. Problem persists and some situations can't be replicated locally where can I debug and put breakpoits. What shall I do to reopen the issue?

[officialpatterson]

I’ll follow this up with more detail later, but I also found that the error can be caused by bad/missing arguments when attempting to use the task.

[wnbittle]

For those still encountering this issue and looking for a workaround - we (@aaramians and I) did the following while we wait for a fix:

1. npm install this package as-is
2. Make the following edits to the package under node_modules:
   1. Copy the English messages from lib.json into the _locStringCache object on line 61 of the internal.js file
   2. Comment out lines 221-226 of the internal.js file
3. Run node pack on that folder to produce a .tgz file
4. Uninstall the module
5. Install the module using the .tgz instead

With webpack enabled we went from 2 MB per task to 100 KB per task.

[cima]

@wnbittle Please provide snippet of the code orr diff to be commented out as different version has different lines.

[wnbittle]

@cima does this gist give you what you need?

[cima]

@wnbittle Yes this block is excatly what I meant.

Howerver since the fix is already released it is more advisable to use the fixed version azure-pipelines-task-lib 3.1.0 or newer.

[cima]

@russellseymour Does the elimination of stack exceeding solves Your problem or does it lead to a discovery of another problem?

[github-actions]

This issue has had no activity in 90 days. Please comment if it is not actually stale