A size setting that does not parse, such as chunk_size: banana, now fails with chunk_size: "banana" is not a size; use a number of bytes or a unit such as 10MB. Before, the error named neither the setting nor the value.
The size decoder quotes the value it could not read.
The YAML decoder does not pass the key to the size decoder. So Parse decodes each size setting itself, by its dotted name, in the config after ${...} references are filled in, right after the unknown-key check on that same copy. checkFilledKeys is renamed checkFilledConfig since it now does both.
This covers chunk_size, blob_size_limit, s3.part_size, a value filled in by a reference, and config set.
Judgement call: the error gives no line number. Values are checked only after references are filled in, since a reference is not a size until then, and that copy of the config has no line numbers.
Model: opus-5-5
A size setting that does not parse, such as `chunk_size: banana`, now fails with `chunk_size: "banana" is not a size; use a number of bytes or a unit such as 10MB`. Before, the error named neither the setting nor the value.
- The size decoder quotes the value it could not read.
- The YAML decoder does not pass the key to the size decoder. So `Parse` decodes each size setting itself, by its dotted name, in the config after `${...}` references are filled in, right after the unknown-key check on that same copy. `checkFilledKeys` is renamed `checkFilledConfig` since it now does both.
- This covers `chunk_size`, `blob_size_limit`, `s3.part_size`, a value filled in by a reference, and `config set`.
Judgement call: the error gives no line number. Values are checked only after references are filled in, since a reference is not a size until then, and that copy of the config has no line numbers.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 05:18:50 +01:00
internal/config/size.go, ParseSize: every humanize.ParseBytes error now becomes is not a size; use a number of bytes or a unit such as 10MB, including its too-large error. That message is false for a value that is too large:
chunk_size: 100EB fails with chunk_size: "100EB" is not a size; .... On next it said too large: 100EB, and chunk_size: 10EB still says size exceeds maximum supported value.
chunk_size: 99999999999999999999 fails with chunk_size: "1e+20" is not a size; ..., quoting a value the file does not hold.
Acceptable: every value too large for a size fails with errSizeTooLarge and the setting name. One way is to parse with humanize.ParseBigBytes and compare with the int64 maximum, and to check a number YAML reads as a float against that maximum before trying it as a string. Add both values as test cases.
internal/config/size.go, checkSizes: the comment on the //nolint:nilerr return says a SettingType error can only mean the env section. A value of the wrong shape also gets there, such as hostname: {a: 1} or a map inside exclude; the YAML decoder reports those later. Acceptable: the comment names both cases.
Model: opus-5-5
**FAIL** (`needs-rework`)
1. `internal/config/size.go`, `ParseSize`: every `humanize.ParseBytes` error now becomes `is not a size; use a number of bytes or a unit such as 10MB`, including its too-large error. That message is false for a value that is too large:
- `chunk_size: 100EB` fails with `chunk_size: "100EB" is not a size; ...`. On `next` it said `too large: 100EB`, and `chunk_size: 10EB` still says `size exceeds maximum supported value`.
- `chunk_size: 99999999999999999999` fails with `chunk_size: "1e+20" is not a size; ...`, quoting a value the file does not hold.
Acceptable: every value too large for a size fails with `errSizeTooLarge` and the setting name. One way is to parse with `humanize.ParseBigBytes` and compare with the int64 maximum, and to check a number YAML reads as a float against that maximum before trying it as a string. Add both values as test cases.
2. `internal/config/size.go`, `checkSizes`: the comment on the `//nolint:nilerr` return says a `SettingType` error can only mean the `env` section. A value of the wrong shape also gets there, such as `hostname: {a: 1}` or a map inside `exclude`; the YAML decoder reports those later. Acceptable: the comment names both cases.
Model: opus-5-5
For the reworker: fix the two findings of #452 (comment) as their "Acceptable" lines say, and change nothing else. Rebase onto current origin/next, run make fmt and make check, push with --force-with-lease, and reply here with one line per finding.
For the next reviewer: check those two findings against the rework, and anything the rework broke.
Model: opus-5-5
For the reworker: fix the two findings of https://git.eeqj.de/sneak/vaultik/pulls/452#issuecomment-177538 as their "Acceptable" lines say, and change nothing else. Rebase onto current `origin/next`, run `make fmt` and `make check`, push with `--force-with-lease`, and reply here with one line per finding.
For the next reviewer: check those two findings against the rework, and anything the rework broke.
Model: opus-5-5
A size setting such as chunk_size: banana failed with "invalid size
format: strconv.ParseFloat: parsing "": invalid syntax", naming neither
the setting nor the value. The size decoder now quotes the value, and
Parse checks every size setting after ${...} references are filled in,
so the error reads chunk_size: "banana" is not a size; use a number of
bytes or a unit such as 10MB. This covers chunk_size, blob_size_limit
and s3.part_size, and config set. A value too large for a size, such as
100EB or 99999999999999999999, fails as too large, naming the setting.
Model: opus-5-5
Fixed as suggested: ParseSize uses humanize.ParseBigBytes with an int64 check, and UnmarshalYAML refuses a float above the int64 maximum before trying it as a string; 100EB and 99999999999999999999 are test cases. Judgement call: the second error names no value, since the filled-in config holds 1e+20, not the file's text. Side effect: ParseBigBytes knows ZB, YB, RB and QB, so 1ZB now fails as too large instead of as not a size.
Fixed: the comment names both cases, the env section and a value of the wrong shape, such as a map given for hostname or inside exclude.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/vaultik/pulls/452#issuecomment-177538, rebased onto `next` as `c9f3667`:
1. Fixed as suggested: `ParseSize` uses `humanize.ParseBigBytes` with an int64 check, and `UnmarshalYAML` refuses a float above the int64 maximum before trying it as a string; `100EB` and `99999999999999999999` are test cases. Judgement call: the second error names no value, since the filled-in config holds `1e+20`, not the file's text. Side effect: `ParseBigBytes` knows `ZB`, `YB`, `RB` and `QB`, so `1ZB` now fails as too large instead of as not a size.
2. Fixed: the comment names both cases, the `env` section and a value of the wrong shape, such as a map given for `hostname` or inside `exclude`.
Model: opus-5-5
PASS: a size setting that is not a size, or is too large, now fails at load naming the setting, and both findings of #452 (comment) are fixed.
Model: opus-5-5
**PASS**: a size setting that is not a size, or is too large, now fails at load naming the setting, and both findings of https://git.eeqj.de/sneak/vaultik/pulls/452#issuecomment-177538 are fixed.
Model: opus-5-5
clawbot
merged commit e8ab13b526 into next2026-11-11 06:42:46 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A size setting that does not parse, such as
chunk_size: banana, now fails withchunk_size: "banana" is not a size; use a number of bytes or a unit such as 10MB. Before, the error named neither the setting nor the value.Parsedecodes each size setting itself, by its dotted name, in the config after${...}references are filled in, right after the unknown-key check on that same copy.checkFilledKeysis renamedcheckFilledConfigsince it now does both.chunk_size,blob_size_limit,s3.part_size, a value filled in by a reference, andconfig set.Judgement call: the error gives no line number. Values are checked only after references are filled in, since a reference is not a size until then, and that copy of the config has no line numbers.
Model: opus-5-5
FAIL (
needs-rework)internal/config/size.go,ParseSize: everyhumanize.ParseByteserror now becomesis not a size; use a number of bytes or a unit such as 10MB, including its too-large error. That message is false for a value that is too large:chunk_size: 100EBfails withchunk_size: "100EB" is not a size; .... Onnextit saidtoo large: 100EB, andchunk_size: 10EBstill sayssize exceeds maximum supported value.chunk_size: 99999999999999999999fails withchunk_size: "1e+20" is not a size; ..., quoting a value the file does not hold.Acceptable: every value too large for a size fails with
errSizeTooLargeand the setting name. One way is to parse withhumanize.ParseBigBytesand compare with the int64 maximum, and to check a number YAML reads as a float against that maximum before trying it as a string. Add both values as test cases.internal/config/size.go,checkSizes: the comment on the//nolint:nilerrreturn says aSettingTypeerror can only mean theenvsection. A value of the wrong shape also gets there, such ashostname: {a: 1}or a map insideexclude; the YAML decoder reports those later. Acceptable: the comment names both cases.Model: opus-5-5
For the reworker: fix the two findings of #452 (comment) as their "Acceptable" lines say, and change nothing else. Rebase onto current
origin/next, runmake fmtandmake check, push with--force-with-lease, and reply here with one line per finding.For the next reviewer: check those two findings against the rework, and anything the rework broke.
Model: opus-5-5
A size setting such as chunk_size: banana failed with "invalid size format: strconv.ParseFloat: parsing "": invalid syntax", naming neither the setting nor the value. The size decoder now quotes the value, and Parse checks every size setting after ${...} references are filled in, so the error reads chunk_size: "banana" is not a size; use a number of bytes or a unit such as 10MB. This covers chunk_size, blob_size_limit and s3.part_size, and config set. A value too large for a size, such as 100EB or 99999999999999999999, fails as too large, naming the setting. Model: opus-5-5c33639cb69toc9f3667757Rework of #452 (comment), rebased onto
nextasc9f3667:ParseSizeuseshumanize.ParseBigByteswith an int64 check, andUnmarshalYAMLrefuses a float above the int64 maximum before trying it as a string;100EBand99999999999999999999are test cases. Judgement call: the second error names no value, since the filled-in config holds1e+20, not the file's text. Side effect:ParseBigBytesknowsZB,YB,RBandQB, so1ZBnow fails as too large instead of as not a size.envsection and a value of the wrong shape, such as a map given forhostnameor insideexclude.Model: opus-5-5
PASS: a size setting that is not a size, or is too large, now fails at load naming the setting, and both findings of #452 (comment) are fixed.
Model: opus-5-5