Follow-on observation from #701, deliberately not fixed there.
#701 pinned encoding: "UTF-8" in the three ruby/scripts/ generators, which
made rb-check-drift locale-independent. The next make check on the same
C-locale machine (non-interactive ssh, no LANG) then failed one layer down,
in rb-test:
ruby/test/basecamp/oauth_resource_discovery_test.rb:27:in 'block in <class:OAuthResourceDiscoveryTest>'
json/common.rb:355:in 'String#encode': "\xE2" on US-ASCII (Encoding::InvalidByteSequenceError)
JSON.parse(File.read(...)) on a fixture, read under the locale's US-ASCII
default external encoding. There are likely more sites of the same shape behind
it — the run stops at the first.
Why this wasn't fixed in #701
The LC_ALL=C hardening was scoped to gates and generator scripts — code
that must behave identically wherever it runs. The test suite has never been
part of that surface: CI's Ruby jobs run under the runners' UTF-8 locale and
have been green for years. The failing environment (a shell with no locale
exported) is nonrepresentative of every supported configuration, so the
release-verification cold check now exports LC_ALL=C.UTF-8, matching CI.
What this issue is
A decision point, not a task: either the test suite under LC_ALL=C becomes a
supported configuration — then the fix is a sweep of unpinned
File.read/JSON.parse across ruby/test/ (and a check of the other SDKs'
suites), plus a CI leg that actually runs it that way, per the existing
per-step LC_ALL: C pattern in test.yml — or it explicitly is not, and this
issue closes as the record of that decision. Adding pins without the CI leg
would be a control nobody exercises; adding the CI leg without deciding the
scope first would be armor before naming the failure.
Follow-on observation from #701, deliberately not fixed there.
#701 pinned
encoding: "UTF-8"in the threeruby/scripts/generators, whichmade
rb-check-driftlocale-independent. The nextmake checkon the sameC-locale machine (non-interactive ssh, no
LANG) then failed one layer down,in
rb-test:JSON.parse(File.read(...))on a fixture, read under the locale's US-ASCIIdefault external encoding. There are likely more sites of the same shape behind
it — the run stops at the first.
Why this wasn't fixed in #701
The LC_ALL=C hardening was scoped to gates and generator scripts — code
that must behave identically wherever it runs. The test suite has never been
part of that surface: CI's Ruby jobs run under the runners' UTF-8 locale and
have been green for years. The failing environment (a shell with no locale
exported) is nonrepresentative of every supported configuration, so the
release-verification cold check now exports
LC_ALL=C.UTF-8, matching CI.What this issue is
A decision point, not a task: either the test suite under
LC_ALL=Cbecomes asupported configuration — then the fix is a sweep of unpinned
File.read/JSON.parseacrossruby/test/(and a check of the other SDKs'suites), plus a CI leg that actually runs it that way, per the existing
per-step
LC_ALL: Cpattern intest.yml— or it explicitly is not, and thisissue closes as the record of that decision. Adding pins without the CI leg
would be a control nobody exercises; adding the CI leg without deciding the
scope first would be armor before naming the failure.