What does it mean for git bisect to produce a merge base which is both bad and good?

Question

I've just performed a lengthy bisect, and received the following output from git:

The merge base ec879c71aa41065af101d1cce61966417e8d53c9 is bad.
This means the bug has been fixed between ec879c71aa41065af101d1cce61966417e8d53c9 and [54abe781c482f51ff4ff534ebaba77db5bd97442 5f93eceab193e255b87e06348b69148647c9d2d9 ea865346a07d965645b520478283d5f003c45227 ec879c71aa41065af101d1cce61966417e8d53c9].

(These commits are from Nixpkgs, if being able to see the surrounding history is useful.)

For the sake of saving horizontal space, I'll use letters A to D for the commits, in the order in which they appear in the message. Here it is again, shortened:

The merge base A is bad.
This means the bug has been fixed between A and [B C D A].

My understanding (from looking at this question) is that, ordinarily, this message means that the bug you're bisecting for was inherited from some other branch which it's now been fixed in – the bug is present in A, but was fixed at some point and is no longer present in B, C, D, and... A?

How is this possible?

Edit: as requested, git bisect log:

$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# bad: [b04b3345f16716f7289724286cdc8474d4758a41] Merge pull request #195082 from cmm/system76-scheduler
git bisect bad b04b3345f16716f7289724286cdc8474d4758a41
# status: waiting for good commit(s), bad commit known
# good: [ec879c71aa41065af101d1cce61966417e8d53c9] Merge staging-next into staging
git bisect good ec879c71aa41065af101d1cce61966417e8d53c9
# good: [5f93eceab193e255b87e06348b69148647c9d2d9] Merge pull request #228171 from bcdarwin/unbreak-pybids-nipype-heudiconv
git bisect good 5f93eceab193e255b87e06348b69148647c9d2d9
# good: [54abe781c482f51ff4ff534ebaba77db5bd97442] Merge pull request #228465 from linsui/python-lsp-ruff
git bisect good 54abe781c482f51ff4ff534ebaba77db5bd97442
# good: [ea865346a07d965645b520478283d5f003c45227] Merge pull request #229005 from r-ryantm/auto-update/protoc-gen-validate
git bisect good ea865346a07d965645b520478283d5f003c45227
# bad: [19ca45e39f1dd7ec9f35cf836c7e7a3ff7f18304] vulkan/update-script: always update to latest upstream tags
git bisect bad 19ca45e39f1dd7ec9f35cf836c7e7a3ff7f18304
# bad: [1e9a1505d5fe92093ca36c41f9bd6279c07fe4d2] Merge branch 'staging' into staging-next
git bisect bad 1e9a1505d5fe92093ca36c41f9bd6279c07fe4d2
# skip: [b394a31dd2d715d0ac71e1e3dee2a1076e512d74] Merge pull request #226253 from trofi/fluidsynth-dev-and-man-output
git bisect skip b394a31dd2d715d0ac71e1e3dee2a1076e512d74
# skip: [b58f4b8439f7f6234f4e66343a450aabe90df590] Merge #226730: python310Packages.watchdog: 2.3.0 -> 2.3.1
git bisect skip b58f4b8439f7f6234f4e66343a450aabe90df590
# skip: [3c2398e35866d75730bf48a05027b1b7bfb00e4c] Merge staging-next into staging
git bisect skip 3c2398e35866d75730bf48a05027b1b7bfb00e4c
# skip: [8af3c74004d5a37e061646d3ff1370c7d6cca446] Merge staging-next into staging
git bisect skip 8af3c74004d5a37e061646d3ff1370c7d6cca446
# bad: [804dc945940ba1bb75994f49d6cd6397b94eb596] neovim-unwrapped: add debug output
git bisect bad 804dc945940ba1bb75994f49d6cd6397b94eb596
# bad: [a08d6979dd7c82c4cef0dcc6ac45ab16051c1169] Merge pull request #218973 from sumnerevans/matrix-synapse-1.78
git bisect bad a08d6979dd7c82c4cef0dcc6ac45ab16051c1169

Answer 1

Just to set the stage: the bisect terminology assumes you're hunting a bug introduction. "good" is the old, good commit, before someone (probably me) introduced the bug, "bad" is the commit that generated the bug report.

So you're hunting through the history between the good and bad commits.

That history is not necessarily linear. Simplest history that will produce this symptom:

          *---A
         /     \
G---*---B---*---D
         \     /
          *---C

If "B", "A" and "D" are bad and C is good, there's no way to write the history that doesn't have a good commit both before and after a bad one. What you want to do next depends, uhh, on what you want to do next. If you're trying to find where in the G---*---B sequence the bug was introduced, do git bisect reset then git bisect start G B, if on the other hand you expected the bug to be fixed and it wasn't, then you're doing a find-the-fix bisect and suss out why it didn't survive the merge. So git bisect reset and then hunt through the bad-old-base to good-new-tips candidates.

As a note, your question is confusing: You say in the text that it reported ec879c71aa41065af101d1cce61966417e8d53c9 is bad, but your bisect log says git bisect good ec879c71aa41065af101d1cce61966417e8d53c9, so you marked it good. So I'm answering for the common case and assuming the contradiction in the question there is a simple c&p error or misread.