Do you have the ignoreParsingErrors property enabled? See https://github.com/jenkinsci/code-coverage-api-plugin/pull/788

drulli thank you very much for the exceptional fast response. I was not specifying it so far and just added the option, i.e. now using

 recordCoverage(ignoreParsingErrors: true, tools: [[parser: 'COBERTURA', pattern: 'Coverage/Report/Cobertura.xml']])

and first tests indicate it works.

I added this extra validation to detect broken XML files. Do you have an idea why there are two methods with the same name and signature in your report file? This indicates that something is broken during the report generation.

I dont know why exactly Unity creates duplicates entries. I informed some other dev to check it.

I can't speak for Unity, but I know where I work we've got some Javascript code that has a function defined in two places in one file (conditionally - one's a mock the other is the real one). That Javascript has code coverage run on it with istanbul, and the result is output in cobertura format so that the Jenkins coverage can parse it. Looking in the xml file, there are two different, legitimate, versions of the function in the file on different lines - but the parsing is only accounting for name and signature, so it errors out with this duplicate error.

So, while maybe rare, there are actually things that can create duplicate methods in a cobertura report. I know nothing about Unity, so I can't say if something similar might be the issue - but it's not necessarily something broken during report generation.

(the ignore errors setting does work around it - and fortunately I suspect one of those duplicates is never called in test, so it's not an immediate problem, but this ticket a parsing bug, not a generator bug)

That Javascript has code coverage run on it with istanbul, and the result is output in cobertura format so that the Jenkins coverage can parse it. Looking in the xml file, there are two different, legitimate, versions of the function in the file on different lines

But these two methods must have a different parent, or am I missing something?

I think you're missing something - but it's admittedly a weird corner case. I'm only passingly familiar with the part of our code that's resulting in this unusual coverage report myself, so I hope I've narrowed this down right. But basically we've got:

class SomeClass {
  static aMethod() {
    if (oneCondition) {
      const firstObject = {
        aFunction() {},
        anotherFunction() {},
      }
    }

    if (anotherCondition) {
      const secondObject = {
        aFunction() {}
        anotherFunction() {},
      }
    }
  }
}

Both copies of aFunction and anotherFunction are recorded in the coverage report from istanbul. The XML file has a methods element that is effectively "flat", having one entry for each function in the file - whether those methods are members of the class or nested functions inside other functions. So the only distinction between the entries is the line number (the line numbers in the xml for those functions appear to be the line numbers where the containing object is defined.. I hope that made sense).

So yeah, it's a bit weird, and we could probably write it differently. But it seems to be a valid case that produces a duplicate - unless there is actually something in this that should be able to distinguish the functions as different that the report is in fact missing, other than the line numbers. I can't think of what that might be, but I don't know the details of the cobertura format.

Had the same issue, but don't know why because my typescript code has no duplicates. I searched in transpiled code but also didn't find any hints. We are using vitest with reporter v8. I think vitest has it's own transpilation...
I found this duplicate in the coverage output:

Anyway, for now this problem is fixed with the `ignoreParsingErrors` flag.
Thanks for the great plugin.

Are the lines 20 and 56 within the same method parseFilterString? Currently the parser assumes that the method contains all lines within one method block. Maybe it would help to notify the vitest team that the format somehow is broken.

No, unfortunately not. Line 56 has nothing at all to do with the problematic function. The project is also organised in a monorepo, maybe that is a problem. 
I also noticed that I have a lot of such duplicates in the xml. The example was just the first one that ran into errors. 
It may also be due to how I bind an anonymous function to a property in an object. Many of the problematic funtions lokk like this.

I will investigate this further and maybe inform the vitest team.
Thx again