• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

hyperledger / fabric-x-committer / 30746799805
91%
main: 91%

Build:
Build:
LAST BUILD BRANCH: fix/696-integration-port-reservation
DEFAULT BRANCH: main
Ran 02 Aug 2026 12:00PM UTC
Jobs 3
Files 131
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

02 Aug 2026 11:57AM UTC coverage: 91.218% (+0.02%) from 91.201%
30746799805

Pull #725

github

liran-funaro
[coordinator] Align VC and verifier manager stream behavior

#### Type of change

- Bug fix
- Test update

#### Description

- Bind both managers to one receive-error classification, `classifyStreamRecvError`. The VC
  manager previously retried an `InvalidArgument` under the sustain policy forever; the verifier
  manager already treated it as non-retryable.
- Skip empty batches in the VC send loop instead of marshalling and sending an empty `VcBatch`.
- Do not forward an empty batch from the verifier's receive loop to the VC manager, which is
  where those empty batches came from. The VC manager already guards its own output this way.
- Record at the VC's receive goroutine what breaks if the two output writes are bound to the
  stream context rather than the manager's: the re-queue becomes reachable on every stream
  failure, the statuses of a re-queued batch are delivered twice, and
  `Service.numTxsInProgress` is decremented twice for one transaction. The existing NOTE stated
  the requirement but not its consequence, which is what makes it easy to undo.

#### Additional details (Optional)

`TestValidatorCommitterManagerX/an_empty_batch_is_not_sent_to_the_vcservice` sends a real batch
first, because the first batch of a stream goes through `splitAndSendToVC`, which already sends
nothing for an empty batch — the empty send is only reachable once that path is behind us. With
the guard removed the test observes three batches on the wire instead of two.

No behavior changed for the failed-forward re-queue itself. The status write is already attempted
first and returns early on failure, so the nodes are never forwarded for a batch whose statuses
were dropped; the reverse ordering cannot be fixed by ordering and is instead held unreachable by
the context wiring, which is what the NOTE now explains.

This touches the same receive and send loops as #724, so whichever merges second needs a trivial
rebase.

#### Related issues

- resolves #721

Signed-off-by... (continued)
Pull Request #725: [coordinator] Align VC and verifier manager stream behavior

21 of 21 new or added lines in 2 files covered. (100.0%)

21 existing lines in 9 files now uncovered.

10564 of 11581 relevant lines covered (91.22%)

33419.17 hits per line

Coverage Regressions

Lines Coverage ∆ File
6
92.09
-2.69% service/coordinator/signature_verifier_manager.go
3
85.12
-1.04% service/sidecar/relay.go
2
81.9
-1.9% service/query/query.go
2
92.35
-0.53% mock/orderer.go
2
97.83
-2.17% service/verifier/verifier_server.go
2
94.82
-0.8% service/coordinator/coordinator.go
2
88.15
2.31% service/vc/database.go
1
94.95
-1.01% loadgen/adapters/common.go
1
80.33
-1.64% utils/utils.go
Jobs
ID Job ID Ran Files Coverage
1 core-db-test - 30746799805.1 02 Aug 2026 12:00PM UTC 100
46.56
GitHub Action Run
2 db-test - 30746799805.2 02 Aug 2026 12:02PM UTC 131
79.28
GitHub Action Run
3 unit-test - 30746799805.3 02 Aug 2026 12:02PM UTC 95
84.73
GitHub Action Run
Source Files on build 30746799805
  • Tree
  • List 131
  • Changed 19
  • Source Changed 0
  • Coverage Changed 19
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Pull Request #725
  • PR Base - main (#30541649421)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc