refactor(qwp): rename sf_max_bytes to sf_max_segment_bytes

[mtopolnik]

Renames the store-and-forward connect-string key sf_max_bytes to sf_max_segment_bytes: the key caps a single SF segment, and the new name says so; it also pairs cleanly with sf_max_total_bytes. The builder method follows: storeAndForwardMaxBytes() is now storeAndForwardMaxSegmentBytes(). Internal identifiers, error messages, and test assertions rename in step, so git grep -iE 'sf[_-]?max[_-]?bytes|storeandforwardmaxbytes' returns zero.

The key shipped only in beta-state releases (1.2.2–1.3.4, not on Maven Central), so this is a hard rename — no alias, no deprecation path.

Part of the cross-repo rename of this key (server, c/rust, go, .NET, python, enterprise, docs land in the same window). This repo sets the naming precedent; the QuestDB server PR bumps its submodule to this branch's commit and should merge right after this one.

Full core test suite is green locally, including the five affected test classes.

Note

The red "Build, test & javadoc (JDK 8)" check is the known MmapSegmentRecoveryFaultTest InternalError flake tracked by #69 — pre-existing #64 code, where C2-inlined async unsafe-fault delivery escapes the converting catch. It reproduced twice on this PR with a different failing test each time, and this diff only touches that code path in one comment line, so it is unrelated to the rename. The fix is #71, which reads the recovery scan via pread instead of the mapping so there is no fault to catch at all — merge #71 first, then rebase/merge this PR to clear the check for good.

🤖 Generated with Claude Code

[mtopolnik]

Review: PR #70

Verdict: Approve. This is a clean, complete, behavior-preserving rename. No Critical or Moderate findings.

What I verified

• Completeness — git grep -iE 'sf[_-]?max[_-]?bytes|storeandforwardmaxbytes' returns zero hits across the whole client repo (the PR body's claim holds), and 32 consistent occurrences of the new names. The case-insensitive pattern also covers the CamelCase field/local (sfMaxBytes, actualSfMaxBytes), so nothing was missed.
• Callsite consistency in build() — all three uses of the renamed local were updated in lockstep: the total-bytes default Math.max(defaultMaxTotal, actualSfMaxSegmentBytes * 2), the CursorSendEngine ctor arg, and startOrphanDrainers(...). Field init to PARAMETER_NOT_SET_EXPLICITLY preserved.
• Error messages — the "invalid …"/"… must be positive" text is threaded from the name argument (parseSizeValue(sink, "sf_max_segment_bytes") → LineSenderException("invalid ").put(name)), so the renamed message and the test assertion (contains("invalid sf_max_segment_bytes")) stay in sync. Both parse paths (legacy fromConfig if/else chain and WS fromConfigWebSocket ConfigView), ConfigSchema INGRESS registration, and wsConfigSnapshotForTest were all renamed.
• Non-production changes are comment-only — MmapSegment.java, SegmentRing.java, CursorWebSocketSendLoop.java, and one SegmentRingTest javadoc are single comment-line edits. The only executable changes are identifier/string renames in Sender.java + one string literal in ConfigSchema.java. No behavioral delta.
• Cross-repo coordination — the parent questdb repo (on the coordinated mt_sf-max-segment-bytes branch) already uses sf_max_segment_bytes in QwpIngressOracleFuzzTest.java with zero old-name references, so the submodule bump won't break the parent build.
• Tests still bite — Sender.fromConfig(...) throws on an unknown key, so the renamed testSfMaxSegmentBytesParsing, assertHonored("sf_max_segment_bytes=4096", ...), and testIngressOnlyKeysSilentlyAcceptedOnEgress exercise the new key through the real parse path and would fail if the rename were incomplete on the ingress side. Assertions are unchanged in substance.
• No binaries in the diff; no Java-8-incompatible constructs introduced.

Minor

• Sender.java:2760 — the public builder method renamed to storeAndForwardMaxSegmentBytes(long maxBytes) but the parameter is still maxBytes. Cosmetic only (no @param javadoc), but for full coherence with the "per segment" semantics it reads better as maxSegmentBytes. The javadoc itself ("Maximum bytes per segment file before rotation") is already correct. Not blocking.
• Hard rename, no alias — a caller still passing the old sf_max_bytes connect-string key now gets a generic unknown-key rejection rather than a "renamed to sf_max_segment_bytes" hint. This is acceptable per project policy (QWP/SF is beta and unreleased; the key shipped only in beta builds 1.2.2–1.3.4, never on Maven Central) and matches the existing accept-union/reject-legacy stance — I'm flagging it only so the choice is explicit, not as a defect.

Summary

• No regressions, no tradeoffs beyond the deliberate hard-rename of a beta key. Ready to merge once the JDK 8 check is green.

[mtopolnik]

[PR Coverage check]

😍 pass : 10 / 14 (71.43%)

file detail

	path	covered line	new line	coverage
🔵	io/questdb/client/Sender.java	9	13	69.23%
🔵	io/questdb/client/impl/ConfigSchema.java	1	1	100.00%