Skip to content

Support "NONE" for max-error-lines in robot.toml#609

Open
dicnunz wants to merge 1 commit into
robotcodedev:mainfrom
dicnunz:fix-max-error-lines-none
Open

Support "NONE" for max-error-lines in robot.toml#609
dicnunz wants to merge 1 commit into
robotcodedev:mainfrom
dicnunz:fix-max-error-lines-none

Conversation

@dicnunz
Copy link
Copy Markdown

@dicnunz dicnunz commented May 20, 2026

Summary

  • allow max-error-lines = "NONE" in the RobotCode config model
  • pass the value through to Robot Framework as --maxerrorlines NONE
  • update generated schemas, reference docs, and profile/config regression coverage

Closes #606.

Verification

  • PYTHONPATH=packages/core/src:packages/robot/src uv run --with pytest --with pytest-mock --with pytest-asyncio --with pytest-rerunfailures --with pyyaml --with tomli-w --with typing-extensions --with robotframework --with platformdirs pytest tests/robotcode/robot/config/test_profile.py tests/robotcode/robot/config/test_model.py tests/robotcode/robot/config/test_toml.py
  • uv run --with ruff ruff check packages/robot/src/robotcode/robot/config/model.py tests/robotcode/robot/config/test_profile.py
  • python3 -m json.tool docs/public/schemas/robot.toml.json >/dev/null && python3 -m json.tool etc/robot.toml.json >/dev/null
  • git diff --check

Paid-fix note

If this closes the config gap and saves maintainer time, I am asking $10 here: https://nicdunz.gumroad.com/l/slop-kill-pass?wanted=true

No issue if this project only handles volunteer contributions; the patch stands either way.

@chatgpt-codex-connector
Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

@dicnunz dicnunz force-pushed the fix-max-error-lines-none branch from 4bd4f68 to 43c3f17 Compare May 20, 2026 19:33
@dicnunz
Copy link
Copy Markdown
Author

dicnunz commented May 20, 2026

Rebased this onto current main (7e0c8819) and pushed the updated branch.

Focused verification after the rebase:

  • PYTHONPATH=packages/robot/src:packages/core/src uv run --with pytest --with pytest-mock --with robotframework --with platformdirs pytest tests/robotcode/robot/config/test_profile.py
  • result: 17 passed
  • git diff --check origin/main..HEAD

The PR is now up to date with the current base; remaining gate is review.

@d-biehl
Copy link
Copy Markdown
Member

d-biehl commented May 20, 2026

Thanks for the contribution.

I’m open to reviewing the actual fix on its technical merits, but I’m not going to leave the paid-fix note uncommented.

Small fixes are welcome. Drive-by contributions can be welcome too. AI-assisted contributions are not a problem either. But this PR looks like a very low-context, likely AI-generated or agent-assisted micro-fix: a few lines changed, some generated files touched, a narrow test added, and then a payment request attached to the PR.

That combination is a big problem.

The PR asks for money while still leaving the real verification, integration, trust, and review work to the maintainers. I have now spent around two hours looking into this PR, writing this comment, and frankly getting increasingly frustrated by the whole situation, including finding similar paid-fix style PRs from you in other GitHub projects. On top of that, the patch itself does not follow the project conventions, so I now also need to review the contribution process issues, verify that the change actually behaves correctly end-to-end, understand and validate the generated file changes, and generally do the integration work that should already have been done before submitting a PR with a payment request attached. That is unpaid maintainer time. If I spent the same time on regular client work, my rate would be at least $150/hour, and you are asking for $10 for this issue?

But this is not about the $10. It is about the mismatch: asking to be paid for a small patch while shifting much more unpaid work onto the project.

I spend a lot of unpaid time keeping RobotCode and parts of the Robot Framework ecosystem alive: maintaining code, helping users, answering questions, preparing talks, looking for sponsorship, going to conferences and user group meetings, and trying to make the project sustainable. Seeing someone unknown to the project show up, apparently pick a small public issue, not follow the documented contribution process, not ask beforehand whether paid work is wanted, and then attach a paid-fix note to the PR is frustrating.

To be blunt: this kind of pattern damages the open-source spirit. It turns public issues into monetization opportunities while maintainers are left with the cost, risk, and long-term responsibility. Honestly, it comes across as if you do not really care what open source actually means or what keeps these projects sustainable in the first place. And I am not talking here about huge projects backed by giant companies with effectively unlimited funding. I am talking about the countless smaller open-source projects that are still heavily used everywhere, depend almost entirely on volunteer work, and where almost nobody gives anything back.

Anyway, if someone shows up asking for money for a fix, I expect the work to be complete and ready for review according to the project’s standards. If I pay for a burger, I expect to receive an actual finished burger, not just the bun with the expectation that I will cook the meat, add the toppings, and clean up the kitchen myself.

Open source is normally different: people contribute imperfect patches, maintainers give feedback, contributors improve things, trust is built over time, and eventually maintainers are comfortable merging contributions quickly because there is already context and collaboration. That is the normal community model.

And sometimes, after someone has been around for a while, contributed consistently, helped others, and built trust, they might reasonably say: “Hey, I would like to take two unpaid days off work to focus on solving this problem — is there any sponsorship, bounty, or support available to help offset that?” That is a completely different situation from showing up out of nowhere with a tiny low-context patch and attaching a payment request to it.

A paid-fix note changes that expectation. A paid-fix note raises the bar; it does not lower it. That does not mean I am agreeing to pay for this PR if the issues below are fixed. Paid work needs to be discussed and agreed before the work is started.

With that context in mind, these are the concrete issues that still need to be addressed before I can review this further:

  1. Unsigned commit

    The commit is not signed, although our contribution guide requires signed commits.

  2. Commit message and PR title

    The commit message does not follow the format documented in the contribution guide:

    <type>(<scope>): <subject>
    

    Please rename it to something like:

    fix(config): allow NONE for max-error-lines
    

    Please also update the PR title accordingly.

  3. Paid-fix note

    Please remove the paid-fix note. We do not accept payment requests, bounty links, invoices, checkout links, or similar solicitation in pull requests unless paid work was discussed and agreed with the maintainers before the work was submitted.

    Fixing the issues in this review will not create any payment obligation.

  4. Verification workflow

    The verification section uses ad-hoc uv run --with ... commands and only runs ruff check and pytest on selected files. The documented workflow in the contribution guidelines uses Hatch, including the configured test environment and commands such as:

    hatch run test:test
    hatch run lint:all

    Please verify the change with the documented Hatch workflow, or explain why your commands are equivalent. A focused uv run --with ruff ruff check ... on selected files is not equivalent to the project lint workflow.

  5. Tests

    The new tests only cover the "NONE" case and stop at config-model serialization. The important user-facing path is:

    robot.toml
    → RobotCode config/profile loading
    → evaluated Robot options
    → RobotCode runner/CLI invocation
    → Robot Framework receives --maxerrorlines NONE
    

    Please add coverage for the real behavior, or explain why it is already covered elsewhere. And if you are already introducing dedicated tests for this option, then please do it properly and also cover the normal integer cases and reasonable boundaries instead of only the single special-case string value.

  6. Generated schema files

    The PR changes generated schema files without following or referencing the documented schema generation workflow from the contribution guide. If the recent commits had actually been reviewed, it should also have been obvious that the schema generation process changed recently. Please regenerate the schema using the documented current project generator workflow and state the exact command used.

  7. Invalid TOML example

    The current example appears to put both values into one TOML block:

    max-error-lines = 40
    max-error-lines = "NONE"

    That is not a valid TOML example because the same key appears twice. Please split this into separate examples or otherwise avoid generating an invalid example.

Again: this is not about whether AI tools were used. To be honest, this PR strongly looks like a low-context AI-generated or agent-assisted patch: a very small change, incomplete verification, generated files touched without explanation, narrow tests, and a payment request attached.

This is about the paid-fix note.

If this PR had simply been submitted as a normal community contribution without the paid-fix note attached, the tone and expectations here would probably have been very different. I would likely still have pointed out many of the same issues, but I would have done so in a much friendlier way, with genuine appreciation that someone took the time to look into the problem. Depending on the remaining effort, I might even have fixed some of the smaller issues myself just to get the change merged and the problem solved.

And another thing: if this had felt like a genuine contribution, the wording and communication around the PR would probably also have been different. Something more along the lines of: “Hey, I’m ..., I noticed this issue and tried to fix it — would this be useful for the project?” Or even just a friendly comment on the original issue discussing the approach. Communication matters.

Instead, your message basically comes across as: “Summary... Verification... If you want, you can pay me.” That is simply not a good tone for an open-source contribution.

If you are genuinely interested in contributing to this project as part of the open-source community and without expecting payment, then please address the points above. If not, that is also fine. I also have AI agents available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Support "NONE" string value for max-error-lines in TOML config

2 participants