sami/vdm
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

proto: fix daemon/engine attribution in two buffer-clamp descriptions

Browse Source 
DAEMON's rebase audit caught it: TaskDetail.effectiveBufferBytes said "the
daemon reduces every live segment's buffer" to fit maxTotalBufferBytes, but
ADR 0011's ownership table (line 55) assigns bufferBytes/maxTotalBufferBytes
to CORE in bytes-units -- DAEMON counts tasks, CORE counts segments and
bytes. "The engine" is correct.

Same error, same root cause, in DownloadSpec.segments: "the daemon lowers it
to the per-host cap" attributes the per-host *segment* cap to DAEMON, but
that's CORE's (ADR 0011 line 54, "CORE enforces per-host segment caps -- it
owns the connections and is the only place segments are counted"). DAEMON's
own per-host cap is a *task*-level admission cap (line 50), a different
thing entirely -- conflating the two in the schema's own prose is exactly
how the clamp ends up implemented twice, once in each lane, disagreeing.

Description-only, no version bump: the JSON Schema shape is untouched, only
which component the prose names as doing the reducing. Regenerated code
diffs are comment-only (doc comments in the generated header and TS types).

Checked every other buffer/segment-clamp description for the same mistake;
the rest either already said "CORE"/"the engine" or used passive voice that
doesn't misattribute (Settings.connection.maxTotalBufferBytes,
Settings.connection.bufferBytes, docs/04, ADR 0012).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV
This commit is contained in:
sami
2026-09-10 00:07:05 +04:00
co-authored by Claude Sonnet 5
parent 6db304a0ae
commit d3ab00d67c
5 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
contracts/openrpc.json
+4 -4
View File
@@ -487,9 +487,9 @@
],
"minimum": 1,
"maximum": 32,
"description": "The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
"description": "The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
},
"description": "The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
"description": "The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
},
{
"name": "bufferBytes",
@@ -3207,7 +3207,7 @@
],
"minimum": 1,
"maximum": 32,
"description": "The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
"description": "The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
},
"bufferBytes": {
"type": [
@@ -4143,7 +4143,7 @@
],
"minimum": 65536,
"maximum": 16777216,
"description": "The write buffer actually in use per live segment, right now. May be well below bufferBytes: the daemon reduces every live segment's buffer to fit connection.maxTotalBufferBytes across connection.maxActiveSegments concurrently-transferring segments, and reports the reduced value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its first segment."
"description": "The write buffer actually in use per live segment, right now. May be well below bufferBytes: the engine reduces every live segment's buffer to fit connection.maxTotalBufferBytes across connection.maxActiveSegments concurrently-transferring segments, and reports the reduced value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its first segment."
},
"partPath": {
"type": [
contracts/schema/types/DownloadSpec.schema.json
+1 -1
View File
@@ -80,7 +80,7 @@
],
"minimum": 1,
"maximum": 32,
"description": "The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
"description": "The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the per-host cap, and to 1 when the source turns out not to be resumable. What is actually in use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload."
},
"bufferBytes": {
"type": [
contracts/schema/types/TaskDetail.schema.json
+1 -1
View File
@@ -65,7 +65,7 @@
],
"minimum": 65536,
"maximum": 16777216,
"description": "The write buffer actually in use per live segment, right now. May be well below bufferBytes: the daemon reduces every live segment's buffer to fit connection.maxTotalBufferBytes across connection.maxActiveSegments concurrently-transferring segments, and reports the reduced value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its first segment."
"description": "The write buffer actually in use per live segment, right now. May be well below bufferBytes: the engine reduces every live segment's buffer to fit connection.maxTotalBufferBytes across connection.maxActiveSegments concurrently-transferring segments, and reports the reduced value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its first segment."
},
"partPath": {
"type": [
core/generated/velox_proto.hpp
+2 -2
View File
@@ -533,7 +533,7 @@ struct DownloadSpec {
std::optional<std::string> categoryId{};
/// Required when startMode is 'queue'.
std::optional<std::string> queueId{};
/// The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the
/// The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the
/// per-host cap, and to 1 when the source turns out not to be resumable. What is actually in
/// use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload.
std::optional<std::int64_t> segments{};
@@ -835,7 +835,7 @@ struct TaskDetail {
/// use.
std::optional<std::int64_t> bufferBytes{};
/// The write buffer actually in use per live segment, right now. May be well below bufferBytes:
/// the daemon reduces every live segment's buffer to fit connection.maxTotalBufferBytes across
/// the engine reduces every live segment's buffer to fit connection.maxTotalBufferBytes across
/// connection.maxActiveSegments concurrently-transferring segments, and reports the reduced
/// value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its
/// first segment.
extension/src/shared/protocol/types.ts
+2 -2
View File
@@ -208,7 +208,7 @@ export interface DownloadSpec {
/** Required when startMode is 'queue'. */
queueId?: string | null;
/**
* The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to
* The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to
* the per-host cap, and to 1 when the source turns out not to be resumable. What is
* actually in use comes back as TaskSummary.segments. null means use
* connection.maxSegmentsPerDownload.
@@ -752,7 +752,7 @@ export interface TaskDetail {
bufferBytes?: number | null;
/**
* The write buffer actually in use per live segment, right now. May be well below
* bufferBytes: the daemon reduces every live segment's buffer to fit
* bufferBytes: the engine reduces every live segment's buffer to fit
* connection.maxTotalBufferBytes across connection.maxActiveSegments
* concurrently-transferring segments, and reports the reduced value here so the GUI can
* show '16 MiB (using 4 MiB)'. null before the task has started its first segment.