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

Fix yargs parsing string arguments as numbers #1881

Closed
t1m0thyj opened this issue Aug 24, 2022 · 4 comments · Fixed by #2237
Closed

Fix yargs parsing string arguments as numbers #1881

t1m0thyj opened this issue Aug 24, 2022 · 4 comments · Fixed by #2237
Assignees
Labels
bug Something isn't working priority-high Production outage - this quarter or at least next quarter severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex. v3 prospective changes for v3

Comments

@t1m0thyj
Copy link
Member

TL;DR Yargs parses string arguments as numbers if they look like numbers, which may be unexpected behavior for methods that expect string values.

After seeing the context of #1883, I think I understand why 🙂 It seems like the default behavior of the yargs parser is to parse any options that look like numbers as numbers (source). This is undesirable behavior for jobid which should be parsed as a string regardless of whether a user enters it in the format JOB1234 or just 1234. Is this correct?

The solution in this PR will fix the issue for this command and any command handlers that call toBeDefinedAndNonBlank. But I wonder if there are any other places where we may hit a similar issue if command handlers call other methods that are expecting a string and receive a number instead.

I am ok with approving this PR as-is if we believe it is the best solution. Alternatively, the behavior of yargs could be overridden (see here) to only parse options of type number as numbers and never parse items of type string. I don't know if we would consider that a bug fix, or a potentially risky breaking change?

Originally posted by @t1m0thyj in zowe/imperative#857 (review)

@t1m0thyj t1m0thyj added bug Something isn't working priority-medium Not functioning - next quarter if capacity permits severity-low Bug that makes the usage of the Zowe less convenient but doesn't impact key use cases labels Nov 29, 2022
@awharn awharn transferred this issue from zowe/imperative Nov 13, 2023
@t1m0thyj t1m0thyj moved this to Medium Priority in Zowe CLI Squad Dec 26, 2023
@adam-wolfe adam-wolfe mentioned this issue Jan 4, 2024
26 tasks
@adam-wolfe adam-wolfe mentioned this issue Apr 19, 2024
23 tasks
@t1m0thyj
Copy link
Member Author

t1m0thyj commented Aug 7, 2024

This issue can happen with the --encoding option as well, when the IBM- prefix is missing (e.g. 939 instead of IBM-939):

When trying to run
zowe jobs view spool-file-by-id [jobid] [spoolFileId]
I get this error message:

Unexpected Command Error:
Please review the message and stack below.
Contact the creator of handler:
"/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/lib/zosjobs/view/spool-file-by-id/SpoolFileById.handler"
Message:
encoding.trim is not a function
Stack:
TypeError: encoding.trim is not a function
    at GetJobs.<anonymous> (/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/node_modules/@zowe/zos-jobs-for-zowe-sdk/lib/GetJobs.js:405:38)
    at Generator.next (<anonymous>)
    at /usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/node_modules/@zowe/zos-jobs-for-zowe-sdk/lib/GetJobs.js:18:71
    at new Promise (<anonymous>)
    at __awaiter (/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/node_modules/@zowe/zos-jobs-for-zowe-sdk/lib/GetJobs.js:14:12)
    at GetJobs.getSpoolContentById (/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/node_modules/@zowe/zos-jobs-for-zowe-sdk/lib/GetJobs.js:398:16)
    at SpoolFileByIdHandler.<anonymous> (/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/lib/zosjobs/view/spool-file-by-id/SpoolFileById.handler.js:41:67)
    at Generator.next (<anonymous>)
    at fulfilled (/usr/local/node-v20.15.0-linux-x64/lib/node_modules/@zowe/cli/lib/zosjobs/view/spool-file-by-id/SpoolFileById.handler.js:15:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

This is on a server. It works on my machine 😀
How can I fix this?
Node version: v20.15.0
Zowe version: 7.28.2

https://openmainframeproject.slack.com/archives/CC8AALGN6/p1722846168243069

@t1m0thyj t1m0thyj moved this from Medium Priority to New Issues in Zowe CLI Squad Aug 7, 2024
@t1m0thyj t1m0thyj added the for-review To be reviewed in an Eng & Prod Mgmt meeting label Aug 7, 2024
@JTonda JTonda added priority-high Production outage - this quarter or at least next quarter v3 prospective changes for v3 and removed for-review To be reviewed in an Eng & Prod Mgmt meeting priority-medium Not functioning - next quarter if capacity permits labels Aug 7, 2024
@zowe-robot zowe-robot moved this from New Issues to High Priority in Zowe CLI Squad Aug 7, 2024
@JTonda JTonda added severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex. and removed severity-low Bug that makes the usage of the Zowe less convenient but doesn't impact key use cases labels Aug 7, 2024
@t1m0thyj
Copy link
Member Author

Tried setting the yargs parser configuration in YargsConfigurer.ts:

yargs.parserConfiguration({
  "parse-numbers": false,
  "parse-positional-numbers": false
})

This prevents numbers from being parsed at all, even for args of type number. It seems that yargs is unable to smartly determine whether an argument should be parsed as a number or not, so we may need to add such logic ourselves.

@traeok
Copy link
Member

traeok commented Aug 19, 2024

yargs has a coerce function that allows you to specify the coercion function for specific keys. I haven't used yargs much but it might be useful for resolving the string/number parsing issue - we could programmatically filter the list of args based on type and then override yargs behavior to attempt parsing those args as numeric. But depending on how yargs is used within the CLI, we might not be able to do this without pre-fetching all the numeric arguments ahead of time.

@t1m0thyj
Copy link
Member Author

I like the idea of the yargs coerce function - we should investigate this, although not sure if we'll be able to access the command definition from within the coercion function to determine what type of argument is being parsed. If not, we may need to parse the arguments ourselves in the Imperative CommandProcessor.

awharn added a commit that referenced this issue Aug 20, 2024
Signed-off-by: Andrew W. Harn <andrew.harn@broadcom.com>
@t1m0thyj t1m0thyj linked a pull request Aug 20, 2024 that will close this issue
4 tasks
@github-project-automation github-project-automation bot moved this from High Priority to Closed in Zowe CLI Squad Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-high Production outage - this quarter or at least next quarter severity-medium Bug where workaround exists or that doesn't prevent the usage of Zowe. Just makes it more complex. v3 prospective changes for v3
Projects
Status: Closed
Development

Successfully merging a pull request may close this issue.

4 participants