Adds a trimmed debug_e2e.cfg (DebugService on 8080/8081, TcpLogger on
9090) and two new scenarios (s55_debug_force_trace_break, kind=debug;
s56_tcplogger_delivery, kind=tcplogger) reusing it, with matching
run_e2e.sh scenario-list/dispatch wiring and debugclient build steps.
Also fixes a real bug found while wiring s56: debugclient's tcplogger
check was tautological (it matched MarteController's own local
"CMD"-level echo of the outgoing command, which contains the same text
as the triggered event, instead of a line actually delivered over the
real TCPLogger TCP socket) and its trigger command (an invalid FORCE)
never reaches DebugServiceBase's REPORT_ERROR at all. Switched the
trigger to a MSG-to-missing-destination command (which does call
REPORT_ERROR) and the match to require the real log text
("not found in ORD"), recorded only after a connect-settle baseline —
verified with a positive run (real Warning-level TCPLogger line
received) and a negative control (LogPort=0 disables TcpLogger and the
scenario correctly FAILs).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Standalone headless client that drives a running MARTeApp.ex's
DebugService (TCP 8080 commands, UDP 8081 trace) and TCPLogger (TCP
9090) via marte2debugger/controller's NewHeadlessMarteController, for
the upcoming Test/E2E/suite "debug"/"tcplogger" scenario kinds. Scripts
FORCE/TRACE/BREAK for -mode debug, and triggers+waits for a TCPLogger
log event for -mode tcplogger; reports PASS/FAIL as
result_<scenario>.json/status_<scenario>.txt in -out.
Extends the scenario-list builder and main loop to actually execute
s52_direct_unicast/s53_direct_multicast (self-contained single-MARTeApp
FileReader->UDPStreamer->UDPStreamerClient->FileWriter round trip) and
s54_recorder (StreamHub BinaryRecorder round trip, ported from
run_recorder_e2e.sh) alongside the existing chain scenarios, and tags
each results.json record with its scenario kind.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Full-chain orchestrator (run_chain_e2e.sh) now runs the starter set green
(3 pass). Fixes found bringing the chain up end-to-end:
- client: gorilla/websocket cannot survive a read deadline (next ReadMessage
panics "repeated read on failed connection"); replace the poll-with-deadline
loop with a background reader goroutine + mutex-guarded state.
- orchestrator: guard env.sh's unbound LD_LIBRARY_PATH under set -u.
- scenarios/gen_data: centralize NUM_ROWS/ROW_DT and enforce sine freq to be a
multiple of the buffer fundamental (LOOP_HZ=5 Hz) so the looped FileReader
buffer is a seamless waveform; align starter freqs (5/5/10 Hz).
- gen_cfg: FileReader allows exactly one consuming Function, so route tapped
(oracle=fed/both) sources through the DDB (ReaderGAM->DDB, then StreamGAM and
TapGAM both read DDB) instead of a second FileReader consumer.
- validate_waveform: fidelity gates correctness (bit-exact / within one quant
level); sine shape becomes a gross frequency-sanity gate (corr>=0.5) plus a
tracked corr/nRMSE quality metric, since per-sample wall-clock calibration
(Phase-A) and FULL_ARRAY packed timestamps (Phase-A4) are still pending.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
End-to-end test streaming three float32 signals via a MARTe2 UDPStreamer
app into a standalone StreamHub with the recorder enabled, then validating
the recorded FileWriter-compatible .bin against the streamed input with
validate_binary.py. All recorded rows are byte-identical to input rows.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Martino Ferrari