Can't find the source of ignored spelling

[OTrkozak]

I have a file:
test.txt

when I run this command on my Windows command line:
cspell check test.txt --config cspell.json

where cspell.json contains
{
"version": "0.2",
"language": "en",
}

I get the following result:

As you can see, paymentqistory is sometimes a spelling mistake and sometimes not. Somewhere in my configuration there must be something that is telling cspell to ignore strings in the form /api/cp/accounts/personal/ since replacing any of the words eliminates the behavior. However, I've done a search everywhere I can think of and that string does not appear. Other developers on the team also have the same behavior on their Windows machines, so I was thinking it had to do with our config, but changing to the minimum config made no difference.

It wouldn't be so bad, except that my build server is linux and when it does the same check (with the original config file), it always identifies this string as a spelling mistake. I've checked, and both installations are using the same set of dictionaries, so that's not the problem either.

Any suggestions where I can find the source of this behavior would be appreciated.

[Jason3S]

@OTrkozak,

Would you please tell me what version of CSpell you are using? cspell -V

I think it is related to the Base64 detection. See #2175. Version ^5.15.0 should work.

You can also try the following:

To disable Base64 checking add the following to your config:

    "patterns": [
        {
            "name": "Base64",
            "description": "Turn off Base64",
            "pattern": "/$^/g"
        },
        {
            "name": "Base64SingleLine",
            "description": "Turn off Base64SingleLine",
            "pattern": "/$^/g"
        },
        {
            "name": "Base64MultiLine",
            "description": "Turn off Base64MultiLine",
            "pattern": "/$^/g"
        }
    ]

[OTrkozak]

Upgrading to 5.15.0 was the answer. Thank you. I was using 5.13.0.

[OTrkozak]

Spoke too soon. I also had to disable Base64 checking with the config provided for it to work in my codebase. The version upgrade fixed a test case so now the result looks like

The last test case still does not indicate an error.

[Jason3S]

I don't think you need the Base64 checking.

It looks more like you are just seeing the maxDuplicateProblems limit.

Changing it to 10 gives me the following:

But there does seem to be a bug, because it is allowing 5-1 instead of 5 as the default.

[Jason3S]

The bug was fixed with #2237