fix: CountItems inflight correction skipped by a BigInt/Number type mix by delthas · Pull Request #407 · scality/s3utils

delthas · 2026-09-17T13:25:31Z

updateInflightDeltas throws on every completed count-items run on any platform with concurrent writes, and the inflight correction is then silently skipped for every bucket and account.

{"method":"updateInflightDeltas","errorString":"TypeError: Cannot mix BigInt and other types, use explicit conversions"}

Observed on a customer platform in two sosreports three months apart, one occurrence per completed run. An idle platform shows zero — consistent with the trigger.

Mechanism

:963 — convertNumberToLong(metrics) turns every bigint into a BSON Long, so by the time updateInflightDeltas runs at :969 both usedCapacity.current and _inflightsPreScan are Long.
:86 — _inflight comes from MongoDB, where promoteLongs defaults to true, so it is a plain Number. The subtraction is Number arithmetic and yields a Number.
:19 — BigIntMax converts both operands to compare them, then returns the unconverted one, so a Number comes back out.
:91 — BigInt(current) + <Number> → TypeError.

Second path: _inflightsPreScan is only stored when non-zero (:414), so a bucket that only gained inflights during the scan gives 5000 - undefined = NaN → BigInt(NaN) → RangeError.

Both are caught at :122, logged once, and allMetrics is returned unmodified.

Fix

Convert at the two boundaries, and make BigIntMax return its converted operands so it cannot launder a type again. The correct pattern already existed at :1035, which reads the same field as BigInt(doc.usedCapacity._inflight.toString()).

The other ten BigIntMax call sites (:690-707, :725, :728) already pass BigInt values against 0n, so that change is a no-op for them.

Why it was never caught

The unit test stubbed the collection with _inflight: 3000n — a BigInt literal MongoDB cannot return, since nothing sets useBigInt64. With BigInt on both sides the arithmetic succeeded and the test passed.

That stub now uses a Number, and two new tests drive the real in-memory MongoDB without stubbing getCollection, so the driver's own conversions are exercised. Both fail on the parent commit with Expected 3900n, Received 1000n — the metric left uncorrected — and pass here.

Regression range

Correct when added (490de27, S3UTILS-163, 1.14.8) — it was written in defensive Number arithmetic. The BigInt migration (1460431, 1.14.18) replaced Math.max with BigIntMax and dropped the Number() / Long.fromNumber() coercions. Affected from 1.14.18 through 1.19.1.

Verification

yarn test:unit locally: 32 suites, 456 tests, all passing. eslint clean.

Issue: S3UTILS-245

`updateInflightDeltas` is reached after `convertNumberToLong` has turned every metric into a BSON Long, and `_inflight` is read back from MongoDB as a Number because `promoteLongs` defaults to true. Neither side of the subtraction is a BigInt, so `BigIntMax` -- which compares as BigInt but returned the unconverted operand -- handed a Number to `BigInt(current) + inflight`, raising: TypeError: Cannot mix BigInt and other types, use explicit conversions `_inflightsPreScan` is also only stored when non-zero, so a bucket which only gained inflights during the scan produced `NaN` and a RangeError from `BigInt(NaN)` instead. Both are caught and logged, and the function then returns the metrics unchanged, so the correction was applied to no bucket and no account: `usedCapacity.current` silently excluded the inflights remaining after the scan, and `_inflightsDelta` was never written. Convert at the two boundaries and make `BigIntMax` return its converted operands so it cannot launder a type again. The existing unit test stubbed the collection with `_inflight: 3000n`, a value MongoDB cannot return, which is why this was never caught; it now uses a Number, and two tests exercise the real in-memory MongoDB so the driver's own conversions are covered. Issue: S3UTILS-245

bert-e · 2026-09-17T13:25:35Z

Hello delthas,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
`/after_pull_request`	Wait for the given pull request id to be merged before continuing with the current one.
`/bypass_author_approval`	Bypass the pull request author's approval	⭐
`/bypass_build_status`	Bypass the build and test status	⭐
`/bypass_commit_size`	Bypass the check on the size of the changeset `TBA`	⭐
`/bypass_incompatible_branch`	Bypass the check on the source branch prefix	⭐
`/bypass_jira_check`	Bypass the Jira issue check	⭐
`/bypass_peer_approval`	Bypass the pull request peers' approval	⭐
`/bypass_leader_approval`	Bypass the pull request leaders' approval	⭐
`/bypass_source_branch_lineage`	Bypass the cross-branch contamination check	⭐
`/approve`	Instruct Bert-E that the author has approved the pull request.		✍️
`/create_pull_requests`	Allow the creation of integration pull requests.
`/create_integration_branches`	Allow the creation of integration branches.
`/no_octopus`	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
`/unanimity`	Change review acceptance criteria from `one reviewer at least` to `all reviewers`
`/wait`	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
`/help`	Print Bert-E's manual in the pull request.
`/status`	Print Bert-E's current status in the pull request.
`/clear`	Remove all comments from Bert-E from the history `TBA`
`/retry`	Re-start a fresh build `TBA`
`/build`	Re-start a fresh build `TBA`
`/force_reset`	Delete integration branches & pull requests, and restart merge process from the beginning.
`/reset`	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

bert-e · 2026-09-17T13:29:08Z

Request integration branches

Waiting for integration branch creation to be requested by the user.

To request integration branches, please comment on this pull request with the following command:

/create_integration_branches

Alternatively, the /approve and /create_pull_requests commands will automatically
create the integration branches.

codecov · 2026-09-17T13:45:03Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 45.32%. Comparing base (c318e92) to head (a9008ef).

Additional details and impacted files

@@                 Coverage Diff                  @@
##           development/1.17     #407      +/-   ##
====================================================
+ Coverage             45.28%   45.32%   +0.04%     
====================================================
  Files                    88       88              
  Lines                  6486     6489       +3     
  Branches               1360     1363       +3     
====================================================
+ Hits                   2937     2941       +4     
+ Misses                 3503     3502       -1     
  Partials                 46       46

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

delthas · 2026-09-18T09:26:34Z

/approve

delthas · 2026-09-18T09:26:38Z

!done 2h

bert-e · 2026-09-18T09:26:45Z

Integration data created

I have created the integration data for the additional destination branches.

this pull request will merge bugfix/S3UTILS-245/countitems-inflight-bigint-mix into
development/1.17
w/1.18/bugfix/S3UTILS-245/countitems-inflight-bigint-mix will be merged into development/1.18
w/1/bugfix/S3UTILS-245/countitems-inflight-bigint-mix will be merged into development/1

The following branches will NOT be impacted:

development/1.13
development/1.14
development/1.15
development/1.16
development/1.4
development/1.7

You can set option create_pull_requests if you need me to create
integration pull requests in addition to integration branches, with:

@bert-e create_pull_requests

The following options are set: approve

bert-e · 2026-09-18T10:11:22Z

I have successfully merged the changeset of this pull request
into targetted development branches:

✔️ development/1.17
✔️ development/1.18
✔️ development/1

The following branches have NOT changed:

development/1.13
development/1.14
development/1.15
development/1.16
development/1.4
development/1.7

This pull request did not target the following hotfix branch(es) so they
were left untouched:

hotfix/1.14.0

Please check the status of the associated issue S3UTILS-245.

Goodbye delthas.

The following options are set: approve

delthas · 2026-09-18T10:12:41Z

S3UTILS-245: logged 2h; transitioned to Done (Fixed)

scality deleted a comment from bert-e Sep 17, 2026

delthas requested review from a team, SylvainSenechal and francoisferrand September 17, 2026 13:30

SylvainSenechal approved these changes Sep 17, 2026

View reviewed changes

francoisferrand approved these changes Sep 17, 2026

View reviewed changes

bert-e merged commit a9008ef into development/1.17 Sep 18, 2026
15 checks passed

bert-e deleted the bugfix/S3UTILS-245/countitems-inflight-bigint-mix branch September 18, 2026 10:11

Navigation Menu

fix: CountItems inflight correction skipped by a BigInt/Number type mix - #407

fix: CountItems inflight correction skipped by a BigInt/Number type mix#407
bert-e merged 1 commit into
development/1.17from
bugfix/S3UTILS-245/countitems-inflight-bigint-mix

delthas commented Sep 17, 2026

Uh oh!

bert-e commented Sep 17, 2026

Uh oh!

bert-e commented Sep 17, 2026

Uh oh!

codecov Bot commented Sep 17, 2026

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

bert-e commented Sep 18, 2026

Uh oh!

bert-e commented Sep 18, 2026

Uh oh!

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

delthas commented Sep 17, 2026

Mechanism

Fix

Why it was never caught

Regression range

Verification

Uh oh!

bert-e commented Sep 17, 2026

Hello delthas,

Uh oh!

bert-e commented Sep 17, 2026

Request integration branches

Uh oh!

codecov Bot commented Sep 17, 2026

Codecov Report

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

bert-e commented Sep 18, 2026

Integration data created

Uh oh!

bert-e commented Sep 18, 2026

Uh oh!

Uh oh!

delthas commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants