Copilot commented on code in PR #13609:
URL: https://github.com/apache/trafficserver/pull/13609#discussion_r3949011220
##########
tests/gold_tests/traffic_ctl/traffic_ctl_test_utils.py:
##########
@@ -165,6 +165,30 @@ def validate_json_contains(self, **field_checks):
self._finish()
return self
+ def validate_is_valid_json(self):
+ """
+ Validate that stdout parses as JSON. Performs no field checks.
+
+ Use this as a regression guard on any command documented to emit JSON.
+ A gold file cannot do this job: yaml-cpp spells null as `~`, which a
+ gold file matches happily but no JSON parser accepts.
+
+ The raw output is echoed to stderr so it survives in the stream files
+ even though the pipeline consumes stdout.
+
+ Example:
+ traffic_ctl.hostdb().status().validate_is_valid_json()
+ """
+ self._cmd = (
+ f'{self._cmd} | python3 -c "'
+ f"import sys, json; "
+ f"raw = sys.stdin.read(); "
+ f"sys.stderr.write(raw); "
+ f"json.loads(raw)"
+ f'"')
Review Comment:
Piping into python makes the shell pipeline’s exit code reflect only the
JSON-parse step, not `traffic_ctl`’s exit status. This can allow tests to pass
even if `traffic_ctl` fails (e.g., non-zero exit but output happens to be
parseable), because the harness ReturnCode check will see the pipeline’s
status. Consider preserving the left-hand command’s exit status (e.g., run
under a shell with `pipefail`, or restructure so `traffic_ctl` is executed and
its return code asserted independently of the parse step).
##########
tests/gold_tests/traffic_ctl/traffic_ctl_test_utils.py:
##########
@@ -467,6 +491,48 @@ def invoke(self, handler: str, params={}):
return self
+class HostDB(Common):
+ """
+ Handy class to map traffic_ctl hostdb options.
+ """
+
+ def __init__(self, dir, tr, tn):
+ super().__init__(tr)
+ self._cmd = "traffic_ctl hostdb "
+ self._dir = dir
+ self._tn = tn
+
+ def status(self, hostname: str = ""):
+ """Get HostDB info (traffic_ctl hostdb status [HOSTNAME])"""
+ self._cmd = f'{self._cmd} status {hostname} '
+ return self
Review Comment:
Command strings are built by interpolating `hostname` directly into a shell
command, which will break if `hostname` contains whitespace or shell
metacharacters (word-splitting / unexpected expansion). Even in test code, it’s
more robust to shell-quote user-provided arguments (e.g., via `shlex.quote`) or
to pass arguments without shell interpolation if the harness supports it.
##########
doc/developer-guide/jsonrpc/jsonrpc-architecture.en.rst:
##########
@@ -74,6 +74,9 @@ Our JSONRPC protocol implementation uses lib yamlcpp for
parsing incoming and o
this allows the server to accept either JSON or YAML format messages which
then will be parsed by the protocol implementation. This seems handy
for user that want to feed |TS| with existing yaml configuration without the
need to translate yaml into json.
+The server emits null values as the literal ``null``, not as YAML's ``~``.
JSON parsers reject ``~``. YAML resolves ``~`` and
+``null`` to the same value. Clients that read the response as YAML see no
change, and the server still accepts YAML input.
Review Comment:
These new lines are quite long for RST and may violate documentation
line-length/style conventions used elsewhere in the developer guide. Consider
wrapping this paragraph more aggressively (additional line breaks) to improve
readability and reduce diff noise in future edits.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
