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

resolveCLIBinary: abstract-cli could not be accessed at the expected path: [] #304

Open
Rulevoid opened this issue Aug 10, 2020 · 3 comments
Labels
bug Something isn't working

Comments

@Rulevoid
Copy link

Rulevoid commented Aug 10, 2020

I'm using Azure Functions to run a nodejs function which consumes the abstract sdk. No issues running this locally, but consistently seeing issues with the resolveCLIBinary function throwing an error when trying to locate the cli. The path that the error spits out is correct and the cli binary is at that path. The deployed artifact has the node_modules directory at root as expected. This same issue was reported in Spectrum in May: https://spectrum.chat/abstract/developers/cant-access-abstract-cli-when-using-the-abstract-sdk-package~2ad41747-e801-4601-8bc2-852dbcb080c2

I have tried nodejs 10.x and 12.x both with the same issue.

Result: Failure Exception: Worker was unable to load function AbstractHook: 'Error: abstract-cli could not be accessed at the expected path: /home/site/wwwroot/node_modules/@elasticprojects/abstract-cli/bin/abstract-cli' Stack: Error: abstract-cli could not be accessed at the expected path: /home/site/wwwroot/node_modules/@elasticprojects/abstract-cli/bin/abstract-cli at resolveCLIBinary (/home/site/wwwroot/node_modules/@elasticprojects/abstract-cli/index.js:20:13) at Object.<anonymous> (/home/site/wwwroot/node_modules/@elasticprojects/abstract-cli/index.js:30:18) at Module._compile (internal/modules/cjs/loader.js:1138:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10) at Module.load (internal/modules/cjs/loader.js:986:32) at Function.Module._load (internal/modules/cjs/loader.js:879:14) at Module.require (internal/modules/cjs/loader.js:1026:19) at require (internal/modules/cjs/helpers.js:72:18) at Object.<anonymous> (/home/site/wwwroot/node_modules/abstract-sdk/dist/endpoints/Endpoint.js:96:15) at Module._compile (internal/modules/cjs/loader.js:1138:30)

@Rulevoid
Copy link
Author

Temporarily fixed by modifying the resolveCLIBinary function to return the binpath without the fs check. Something is wrong with the fs access check.

@Rulevoid
Copy link
Author

Rulevoid commented Aug 11, 2020

Example of changes that are working.

  const binDir = resolveBinDir();
  if (process.platform === "darwin" || process.platform === "linux" || process.platform === "win32") {
    const binPath = path.join(binDir, BINARY_NAME);
    return binPath;
    
    // try {
    //   fs.accessSync(binPath, fs.constants.R_OK | fs.constants.X_OK);
    //   return binPath;
    // } catch (error) {
    //   throw new Error(
    //     `${BINARY_NAME} could not be accessed at the expected path: ${binPath}`
    //   );
    // }
  }
  throw new Error(
    `${BINARY_NAME} not supported on platform: ${process.platform}`
  );

@tommoor tommoor added the bug Something isn't working label Aug 17, 2020
@tommoor
Copy link
Contributor

tommoor commented Aug 17, 2020

Thanks for all the additional info here 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants