test(windows): read settings files via cygpath in sqlite readfile() (#184)#187
Draft
fujibee wants to merge 1 commit into
Draft
test(windows): read settings files via cygpath in sqlite readfile() (#184)#187fujibee wants to merge 1 commit into
fujibee wants to merge 1 commit into
Conversation
…184) The delivery tests assert on the JSON that 'delivery set' writes by reading it back through sqlite3 readfile(). On native Windows / Git Bash, sqlite3 only reads a Windows path (C:\Users\...), not a POSIX one (/c/... or /tmp/...) — an unconverted path reads back as empty, so json_extract/json_valid see nothing and the assertion fails even though the file the script wrote is correct and valid. Production already converts these paths with cygpath -w (sql_readfile_path / agmsg_sql_readfile_path); the test harness did not. Add an rf() helper (cygpath -w + SQL-literal escape, a no-op off Windows) and route every readfile('<path>') in the delivery/team tests through it. This makes the #184 'wrong count / invalid JSON' failures on the windows-latest experimental leg pass without changing any production behavior — they were a test-harness path-form gap, not a delivery bug. The #134 quoted-path cases stay as-is (already SQL-escaped, skipped on Windows). Confirmed on the windows-latest full leg: all 13 #184 delivery tests (A/B/C, incl. the #95 E2BIG large-settings round-trips) pass with this change. Diagnosis confirmed on a real Windows 11 + Git Bash environment by @Tsuki8825 in #184 (writefile via a C:\ path is clean/valid; a POSIX path writes 0 bytes).
fujibee
force-pushed
the
fix/windows-delivery-paths
branch
from
7338828 to
e1d9529
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the cluster of
delivery setfailures on thewindows-latest (full, experimental)leg tracked in #184.Root cause
The delivery tests assert on what
delivery setwrites by reading the file back through sqlite3readfile(). On native Windows / Git Bash, sqlite3 reads only a Windows path (C:\Users\...), not a POSIX one (/c/...or/tmp/...) — an unconverted path reads back empty, sojson_extract/json_validsee nothing and the assertion fails even though the file the script wrote is correct and valid. Production already converts these paths withcygpath -w(sql_readfile_path/agmsg_sql_readfile_path); the test harness did not. So these were a test-harness path-form gap, not a delivery bug.Fix
tests/test_helper.bash: add anrf()helper —cygpath -w+ SQL-literal escape, a no-op off Windows — mirroringscripts/lib/storage.sh'sagmsg_sql_readfile_path.readfile('<path>')intest_delivery.bats/test_team.batsthroughrf(). The Windows compatibility: malformed JSON in delivery.sh + actas_lock_sid_alive() always false #134 quoted-path cases are left as-is (already SQL-escaped, skipped on Windows).No production behavior changes. Off Windows the helper is a pass-through, so Linux/macOS stay green (delivery + team: 136/0 locally). Pushed as a draft to let the windows-latest leg confirm the #184 tests go green.
Diagnosis confirmed on a real Windows 11 + Git Bash environment by @Tsuki8825 in #184 (writefile via a
C:\path is clean/valid; a POSIX path writes 0 bytes).