10000 UX: better error message for json errors while parsing options by mstoykov · Pull Request #4602 · grafana/k6 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

UX: better error message for json errors while parsing options #4602

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

Merged
merged 2 commits into from
Mar 12, 2025

Conversation

mstoykov
Copy link
Contributor
@mstoykov mstoykov commented Mar 5, 2025

What?

This predominantly tries to actually list the problematic part of the options.

Why?

Hopefully help users figure out what the problem is

Checklist

  • I have performed a self-review of my code.
  • I have commented on my code, particularly in hard-to-understand areas.
  • I have added tests for my changes.
  • I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

  • I have added the correct milestone and labels to the PR.
  • I have updated the k6-documentation: grafana/k6-docs#PR-NUMBER
  • I have updated the TypeScript definitions: grafana/k6-DefinitelyTyped#PR-NUMBER
  • I have updated the release notes: link

Related PR(s)/Issue(s)

This predominantly tries to actually list the problematic part of the
options.
@mstoykov mstoykov added the ux label Mar 5, 2025
@mstoykov mstoykov added this to the v1.0.0-rc1 milestone Mar 5, 2025
@mstoykov mstoykov requested a review from a team as a code owner March 5, 2025 14:07
@mstoykov mstoykov requested review from inancgumus and joanlopez and removed request for a team March 5, 2025 14:07
joanlopez
joanlopez previously approved these changes Mar 5, 2025
nextNewLineIndex := max(bytes.IndexByte(data[e.Offset:], '\n'), len(data)-1)

info := strings.TrimSpace(string(data[previousNewLineIndex:nextNewLineIndex]))
err = fmt.Errorf("parsing options from script got error while parsing %q: %w", info, e)
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: The function name looks pretty generic, while in a large package, and while this error formatting operation is quite specific, thus I'm concerned someone could use it by mistake (expecting it to behave in a more generic way). Wdyt? Perhaps we can set a slightly more concrete name?

Copy link
Member
@inancgumus inancgumus Mar 7, 2025

Choose a reason for hiding this comment

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

If you don't mind longer functions, I usually find it useful to bring related functionality together. So, this function can go into a closure in the populateExport function if we want to avoid others using it as a generic function. Doing so will also save us from finding a better name for it. No strong opinion, though :)

@mstoykov mstoykov merged commit ebb5f67 into master Mar 12, 2025
28 checks passed
@mstoykov mstoykov deleted the betterOptionsJSONError branch March 12, 2025 16:49
mstoykov added a commit that referenced this pull request Mar 13, 2025
The original idea of #4602 was to report at least the key with
potentially the option in question. Due to the lack of support from the
error - it can't parse it. The commit was trying to get everything
between the previous and next new line.

But in practice was getting anything until the end, both because of
error in the coed to get the index, but also because there were no
newlines due to how we marshal the data before that.

This should fix both and make it less likely we just get everything
until the end.
mstoykov added a commit that referenced this pull request Mar 13, 2025
The original idea of #4602 was to report at least the key with
potentially the option in question. Due to the lack of support from the
error - it can't parse it. The commit was trying to get everything
between the previous and next new line.

But in practice was getting anything until the end, both because of
error in the coed to get the index, but also because there were no
newlines due to how we marshal the data before that.

This should fix both and make it less likely we just get everything
until the end.


Co-authored-by: Oleg Bespalov <oleg.bespalov@grafana.com>
Co-authored-by: Ivan <2103732+codebien@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0